[Qbs] Deployment and dependency bundling
oswald.buddenhagen at gmx.de
Wed Jan 1 23:08:14 CET 2020
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,
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".
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
> 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
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).
More information about the Qbs