[Qbs] Deployment and dependency bundling

[Oswald Buddenhagen]

On Sat, Dec 28, 2019 at 08:45:26PM +0300, Alberto Mardegan wrote:
>On 27/12/19 21:24, Oswald Buddenhagen wrote:
>> "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?
>
yes, but given that you're working on this stuff, having the "ideal 
world" (which is actually just pragmatism with a strategic view) on the 
radar seems prudent.

>> 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"?
>
the port of qt to qbs, which was at alpha quality about 16 months ago, 
before it was backstabbed by tqtc's great "leadership".  
https://codereview.qt-project.org/q/branch:wip/qbs2

i don't remember whether the plugin handling went into the port or qbs 
proper (the latter seems more likely).

>>>    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.
>
i don't see anything in that file that contradicts my assertion.
whether a particular module should be considered a system one should be 
decided by the module provider depending on host system and the detected 
module configuration. occasional tweaks might be necessary, but that 
would happen in the module providers, which would come with qbs.
but even assuming that the user needs overrides, that would still happen 
with the granularity of modules, by their name.

>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?
>
we've been asking these questions ourselves since the beginning - see 
QBS-16 and everything linked from there. ^^
dependency embedding, like "regular" install, can be a target that 
operates on the existing products.
but usually, some additional files are needed, even for a mac bundle 
that doesn't need any actual packaging.
a separate product would require seemingly useless boilerplate for 
simple projects.
one could auto-create a packaging product unless specified otherwise, 
but that's magic.
but designating some product to be the "primary" one that also 
determines the packaging would be wrong in the case of a proper 
installer/package that potentially contains multiple applications 
between which no clear hierarchy exists.
i guess apk/bundle/appimage are simply a different use case than 
msi/pkg/rpm - while the underlying mechanism of embedding dependencies 
into the product would be the same, the product in which this happens 
would differ between cases (primary app vs. separate).