<div dir="ltr">Hi,<br><br>I am back at testing this approach from a couple of years back. I now have QBS 1.8, and there I get a new (if not entirely different) set of challenges. The original story is in the old part of the thread, but I suppose I should retell it as I think some things have changed, and I don't remember the full story from before.<br><br>First though I note that QBS-807 haven't been resolved, which may or may not affect this.<br><br>The application itself is minimal (just main.cpp + some qml files), linking various libraries, and eventually loading some Qt plugins.<br><br>The application depends on a library called LauncherLib, which again depends on 2 3rdparty libraries, kdreports and log4qt, with qmake project files. LauncherLib exposes these dependendencies using Export { }.<br><br>So I have a QmakeBuilder module that takes a .pro file, and try to build it (running qmake, then make). The Rule create the product with an Artifact. The file tag of the artifact is set to product.type (well, at least I'm trying that).<br><br>I first just tried to set the type to "dynamiclibrary", and this built kdreports just fine. log4qt however, seems to abort silently at some point in the execution of make. (I can enter the build dir, run make manually, and it completes it.) Qbs doesn't notice it seems, and tries to link the application which fails with a file not found error from g++.<br><br>If I change type to dynamiclibrary_copy for log4qt, it completes building.<br><br>In both cases, the application doesn't actually link (see generated command line below), the problem being I think that liblog4qt is presented before libLauncherLib. kdreports is here again working just fine.<div><br></div><div>I was able to get a different issue at some point, where liblog4qt wasn't present in the link command at all, but currently it is there, but in the wrong place. I was trying to read the code, but couldn't entirely figure out what was going wrong.</div><div><br></div><div>I will see if I can reduce it to a propert minimal example, but I'm still uncertain how much the .pro files themselves affect this result.</div><div><br></div><div>A different approach is of course to just convert the project files to pure qbs, but I was thinking that this was in theory a simpler approach to integrating qmake with qbs, especially if the 3rdparty libs are updated.<br><br>linking Launcher <br><br>/usr/bin/g++ -Wl,-m,elf_x86_64 -Wl,-rpath,/home/larsivi/Qt/5.7/gcc_64/lib -L/home/larsivi/Qt/5.7/gcc_64/lib -L/usr/lib64 -m64 -o /home/larsivi/code/build-Foo-Desktop_Qt_5_7_1_GCC_64bit4-Debug/qtc_Desktop__891cb024-debug/Launcher.qtc-Desktop--891cb024.9923dfd6/Launcher /home/larsivi/code/build-Foo-Desktop_Qt_5_7_1_GCC_64bit4-Debug/qtc_Desktop__891cb024-debug/Launcher.qtc-Desktop--891cb024.9923dfd6/.obj/3a52ce780950d4d9/main.cpp.o /home/larsivi/code/build-Foo-Desktop_Qt_5_7_1_GCC_64bit4-Debug/qtc_Desktop__891cb024-debug/Launcher.qtc-Desktop--891cb024.9923dfd6/.obj/3a52ce780950d4d9/qrc_launcher_resources.cpp.o /home/larsivi/code/build-Foo-Desktop_Qt_5_7_1_GCC_64bit4-Debug/qtc_Desktop__891cb024-debug/Log4Qt.qtc-Desktop--891cb024.23f665f4/.build/liblog4qt.so.1.1.0 /home/larsivi/code/build-Foo-Desktop_Qt_5_7_1_GCC_64bit4-Debug/qtc_Desktop__891cb024-debug/LauncherLib.qtc-Desktop--891cb024.f893036c/libLauncherLib.so /home/larsivi/code/build-Foo-Desktop_Qt_5_7_1_GCC_64bit4-Debug/qtc_Desktop__891cb024-debug/KDReports.qtc-Desktop--891cb024.ab3f794b/.build/libkdreports.so.1.7.0 /home/larsivi/code/build-Foo-Desktop_Qt_5_7_1_GCC_64bit4-Debug/qtc_Desktop__891cb024-debug/CryptoPP.qtc-Desktop--891cb024.4071db54/libcryptopp.a /home/larsivi/code/build-Foo-Desktop_Qt_5_7_1_GCC_64bit4-Debug/qtc_Desktop__891cb024-debug/CoreLib.qtc-Desktop--891cb024.3bbd8f85/libCoreLib.so /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Core.so.5.7.1 -lpthread /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Gui.so.5.7.1 /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Core.so.5.7.1 -lpthread /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Network.so.5.7.1 /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Core.so.5.7.1 -lpthread /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Qml.so.5.7.1 /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Network.so.5.7.1 /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Core.so.5.7.1 -lpthread /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Quick.so.5.7.1 /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Qml.so.5.7.1 /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Gui.so.5.7.1 /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Network.so.5.7.1 /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Core.so.5.7.1 -lpthread /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Widgets.so.5.7.1 /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Gui.so.5.7.1 /home/larigesu/Qt/5.7/gcc_64/lib/libQt5Core.so.5.7.1 -lpthread<br><br><br>Best regards,</div><div>Lars Ivar Igesund<br><br><br><br>On Tue, May 12, 2015 at 11:03 AM Christian Kandeler <<a href="mailto:christian.kandeler@theqtcompany.com">christian.kandeler@theqtcompany.com</a>> wrote:<br><br>On 05/12/2015 10:33 AM, Lars Ivar Igesund wrote:<br> >      > I'm in the process of converting a largish QMake based project to<br> >     QBS.<br> >      > Part of the project are two 3rd party libraries that we have to build<br> >      > ourselves, but that comes with .pro files. With QMake this was very<br> >      > simple, just subdirs them, but with QBS things are a bit more<br> >     cumbersome.<br> >      ><br> >      > What I have done is to create a Module that can do the building, and<br> >      > then define a product that depends on that module with the<br> >     pro-file in<br> >      > the files-list.<br> >      ><br> >      > One feature I wanted, was that when our part of the project<br> >     depends on<br> >      > these qmake-products, then the resulting library files should be<br> >     picked<br> >      > up and automatically linked (as if they were built with qbs).<br> >      ><br> >      > Currently it works in fresh builds, but there are some quirks and<br> >     issues.<br> >      > 1) I was not able to make the automatic linking work unless I set<br> >     output<br> >      > fileTags to be dynamiclibrary_copy (rather than dynamiclibrary),<br> >     which<br> >      > seems wrong as long as I had to dig in the source to find that<br> >      > particular tag.<br> ><br> >     The copy is what gets linked against. When qbs builds a dynamic library,<br> >     it only updates the copy if the list of global symbols has changed, in<br> >     order to not relink unnecessarily. A better tag name would by<br> >     dynamiclibrary_import, like for MSVC's .lib files.<br> ><br> ><br> > If I use dynamiclibrary_import rather than _copy, it doesn't link. With<br> > _copy it links.<br> <br> Sure, that's the actual name of the tag. I was talking about what would<br> perhaps have been a better name.<br> <br> >      > 2) When running clean and/or rebuild, things fails for some<br> >     reason. The<br> >      > built libraries are cleaned, but they are not rebuilt. Looking at the<br> >      > output, it shows that make says "Nothing to be done".<br> ><br> >     So qbs is doing its job by calling qmake and make.<br> ><br> >       > Maybe this is<br> >      > because I don't scan or otherwise set up proper dependencies for<br> >     these<br> >      > projects as a whole? But I would think that since make generates the<br> >      > actual library, it should also figure out that its end target is<br> >     missing.<br> ><br> >     If make says that its targets are up to date, then the file it believes<br> >     to be the top-level artifact is still there. Possibly some problem<br> >     related to DESTDIR? E.g. qbs has removed the file in DESTDIR, but there<br> >     is a copy lying around somewhere that make considers its output<br> >     artifact? I can only guess here.<br> ><br> ><br> > The reason was versioning, such that I got libFoo.so, libFoo.so.1, etc.<br> > It seems like it is somewhat clumsy to avoid generating the version<br> > numbers with Qmake, although it is possible. I see that this doesn't<br> > appear to be the default behaviour of of QBS - how would I go about<br> > getting the symlink set that Qmake generates?<br> <br> Not sure. qbs creates as many symlinks as the product's version has<br> components (up to three). Perhaps qmake's VERSION variable behaves<br> similarly; you'll have to try.<br> <br>  > And in this case, would I<br> > have to make an artifact for each to map them into QBS?<br> <br> Presumably. The tag is "dynamiclibrary_symlink".<br> <br> >      >      Artifact {<br> >      >        // NOTE: Use a subdirectory to avoid default install<br> >     behaviour of<br> >      > moving then deleting potentially<br> >      >        // causing product itself to be deleted<br> ><br> >     ???<br> >     Nothing gets deleted when installing.<br> ><br> ><br> > If all destdirs are set to nothing, the folder it tries to install the<br> > library from is the same folder that it already has been written to.<br> > Then it deletes the old installed library, before copying the in the new<br> > one, but then it isn't there because the old library was actually tne<br> > new one ;) So, yes, probably caused by how I set DESTDIR when I started<br> > on this.<br> <br> Installing has nothing to do with DESTDIR.<br> <br> <br> Christian<br> <br> _______________________________________________<br> QBS mailing list<br> <a href="mailto:QBS@qt-project.org">QBS@qt-project.org</a><br> <a href="http://lists.qt-project.org/mailman/listinfo/qbs">http://lists.qt-project.org/mailman/listinfo/qbs</a></div></div>