Re: [Qbs] Depending on a library that is both shared and static

2020-02-20 Thread Jochen Ulrich
Hi Uwe!

I would probably create two products: one for the static library and one for 
the dynamic library and I would make the dynamic library depend on the static 
library:

StaticLibrary {
name: "mylibrary-static"
targetName: "mylibrary"
// ...
}

DynamicLibrary {
name: "mylibrary-dynamic"
targetName: "mylibrary"
Depends { name: "mylibrary-static" }
// ...
}

Note that it is *not* necessary to list the source files inside the 
DynamicLibrary again unless they should be compiled differently (different 
preprocessor defines or similar).
So this will even reduce compile time because the code is compiled only once.

Best
Jochen


´╗┐Am 20.02.20, 09:26 schrieb "Qbs im Auftrag von Uwe Salomon" 
:

Hello,

I've got a question regarding better control of the "Depends" item when
pulling a library that is built both shared and static.

For library projects that are to be packaged for Debian or Ubuntu, I find it
useful to set up the library's Product like this:

DynamicLibrary {
  targetName: "mylibrary"
  type: ["dynamiclibrary", "staticlibrary"]
  //...
  Group {
fileTagsFilter: ["dynamiclibrary", "dynamiclibrary_symlink", 
"staticlibrary"]
qbs.install: true
qbs.installdir: ...

This way, both the dynamic and the static library are built and installed
(in the staging directory), and can then be put into the Debian package --
the dynamic library into the "libmylibrary1" package, the static library
into the "libmylibrary-dev" package.

Problems arise, however, if one uses a Depends item in a Product in the
same Project for the library. This is necessary in the following cases:

1. a test executable that tests the library
2. some other executable that uses the library
3. another library that uses the library

Usually, one would like to link to the shared library for cases 2 and 3, and
for case 1 the decision depends on whether the test is a true blackbox test
(shared is fine) or a whitebox test (static often necessary).

However, Qbs always links to the static library in these cases. That's
problematic for several reasons.

Do you have any idea how I could control which version of the library is
being pulled into the consuming Product?

Regards,
Uwe
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs


[Qbs] Depending on a library that is both shared and static

2020-02-20 Thread Uwe Salomon
Hello,

I've got a question regarding better control of the "Depends" item when
pulling a library that is built both shared and static.

For library projects that are to be packaged for Debian or Ubuntu, I find it
useful to set up the library's Product like this:

DynamicLibrary {
  targetName: "mylibrary"
  type: ["dynamiclibrary", "staticlibrary"]
  //...
  Group {
fileTagsFilter: ["dynamiclibrary", "dynamiclibrary_symlink", 
"staticlibrary"]
qbs.install: true
qbs.installdir: ...

This way, both the dynamic and the static library are built and installed
(in the staging directory), and can then be put into the Debian package --
the dynamic library into the "libmylibrary1" package, the static library
into the "libmylibrary-dev" package.

Problems arise, however, if one uses a Depends item in a Product in the
same Project for the library. This is necessary in the following cases:

1. a test executable that tests the library
2. some other executable that uses the library
3. another library that uses the library

Usually, one would like to link to the shared library for cases 2 and 3, and
for case 1 the decision depends on whether the test is a true blackbox test
(shared is fine) or a whitebox test (static often necessary).

However, Qbs always links to the static library in these cases. That's
problematic for several reasons.

Do you have any idea how I could control which version of the library is
being pulled into the consuming Product?

Regards,
Uwe
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs