[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