Re: [Qbs] Deployment and dependency bundling

[Alberto Mardegan]

Ho Oswald,

On 27/12/19 21:24, Oswald Buddenhagen wrote:
> you're mixing up two separate issues.
> 
> "deployment" (you actually mean dependency embedding) is just a special
> form of "linking" dependencies. you should be able to make a fully
> static build or a bundle with embedded dlls and plugins from the same
> project, by flipping a single bit. similarly, for qml, you could select
> whether the qml files are compiled (with the old qml compiler) or
> embedded as-is.

Yes. But you are describing the ideal world, not the current situation,
right? QBS with Android already works like this, but for the desktop
platforms that's not yet the case (I'm not sure about Windows, but on
Linux and MacOS one still has to run {linux,mac}deployqt).

> _what_ gets depended upon is a policy decision that is independent from
> the mechanism that does the linking.
> plugins specify a type, while modules declare what types of plugins they
> want to pull in. that makes this policy implicit, and a manual override
> is provided. that was actually already implemented for the qt port.

I guess I miss some history here; what do you mean with "qt port"?

[...]
>>     * Additional properties could be used to exclude some libraries
>>     * from being deployed (because we assume they exist in the
>>     * target system).
>>     */
>>    deployment.excludePatterns: [ "libstdc++.so*", "libxcb.so*" ]
>>
> the embedding property should apply to abstract modules (and their
> "slices", i.e., files that fall into a particular category), not
> os-specific files.  yes, that means that there need to be modules for
> "system" dependencies, and they should be declared as such (so that
> projects don't need to repeat the exclusions each time).

In those cases where the exclusions are well-known, yes. But for
AppImage the situation is rather foggy: the list of exclusions is not
defined by any SDK, but it's the result of a trial and error effort,
greatly depending on application developers submitting bug reports; a
look at the history of the excludelist file in the AppImage repository
[1] is enough to understand that we cannot consider it stable, and we'll
always have at least to provide a way to override parts of it.
But I agree, that we should consider this to be an exception rather than
the rule.

What I'm still missing is an understanding of how this would look like
from the point of view of the QBS user: do we agree that the installable
package (MSI, PKG, AppImage, etc.) should be a different Product, or do
we want to generate it when building the Application?
Do we want to expose the different steps (dependency embedding and
generation of the installable package file) to the QBS user (maybe as
two different products?), or should they both happen together?

Ciao,
  Alberto


[1]: https://github.com/AppImage/pkg2appimage/commits/master/excludelist

-- 
http://www.mardy.it - Geek in un lingua international
___
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs

Re: [Qbs] Deployment and dependency bundling

[Richard Weickelt]

> I've got it working to some point by adding these properties to the Rule:
> 
> inputsFromDependencies: ["application", "dynamiclibrary"]
> multiplex: true
> outputFileTags: ["deployed_library"]
> 
> but this causes the Rule to be run only for the application's
> dependencies, and not for the application itself. Adding
> 
> inputs: ["application"]
> 
> seems to solve the issue, however for some strange reason (at least,
> strange to me) if the Product using this module is not an application,
> but a shared library, QBS will try to also build the product as an
> application (and this will fail, not last because main() is not
> defined). This is not a big issue, since anyway I'd expect this module
> to be used only for applications, but if possible I'd like to avoid
> hardcoding the input to "application".

Are you sure you haven't added "application" by accident to the output file
tags in your rule or as additionalProductType in your module? Please create
a minimal and complete example showing this behavior and open a bug report
if the problem persists.

> I also tried replacing the `inputs` property with
> 
>inputs: products.type
> 
> but this causes QBS to fail with this error:

I guess you have added "deployed_library" somehow to the product's type in
order to run the rule. This would create a cycle.

> Or maybe my approach is totally off, and it would be better to implement
> dependency deployment as a Product 

A separate product is the usual way:
https://code.qt.io/cgit/qbs/qbs.git/tree/src/shared/bundledqt/bundledqt.qbs
https://github.com/bjorn/tiled/blob/master/dist/distribute.qbs

These are rather pragmatic solutions, but of course not very beautiful.

> (since, ultimately, one would use it
> to obtain a MacOS package, an AppImage or a MSI package?)?
> Then, I suppose, just `inputsFromDependencies: ["application"]` would be
> enough?

Are you sure you want to go that far? I have some doubts that this would be
maintaible. Note that win/mac/linux-deployqt exist for a reason. And since I
supose that >99% of Qbs-managed desktop applications are based upon Qbs, it
might make sense to create a generic wrapper module for those tools.

You are currently only writing about resolving ELF dependencies with ldd.
Sure, ldd is available in every Linux distribution. But what about Windows
(PE)? Which dependency analyzer are you going to use? Windeployqt for
instance comes with its own code (which doesn't compile for Linux targets btw.).

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