github-starred/qmlnet

Fork 0

mirror of https://github.com/qmlnet/qmlnet.git synced 2026-05-15 14:15:54 -06:00

[GH-ISSUE #87] Moving Qt binaries into external packages that can be dynamically downloaded? #56

New issue

Closed

opened 2026-05-05 11:02:27 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 11:02:27 -06:00

Owner

Originally created by @pauldotknopf on GitHub (Dec 23, 2018).
Original GitHub issue: https://github.com/qmlnet/qmlnet/issues/87

Currently, we have these packages:

Qml.Net.WindowBinaries
Qml.Net.LinuxBinaries
Qml.Net.OSXBinaries

Each of these packages contains the entire Qt/QML runtime, as well as a lib required by Qml.Net to interoperate (libQmlNet.so). That means each build/release contains the entire Qt/QML runtime, even though the Qt version stays the same.

I'm thinking of updating the above packages to only contain the libQmlNet.so needed for Qml.Net to work. The Qt/QML runtime will be dynamically downloaded and installed either at runtime, or during deployment. I will host the tarballs on GitHub. Each tarball will have a "version.txt" that will declare the Qt version. On startup of the app, if a Qt/QML runtime isn't detected, it will be downloaded.

If you are deploying your app for production, chances are, you don't want users to dynamically download Qt/QML. Instead, you can download the archive yourself, and reference it via a QMLNET_QML_RUNTIME_LOCATION environment variable.

Originally created by @pauldotknopf on GitHub (Dec 23, 2018). Original GitHub issue: https://github.com/qmlnet/qmlnet/issues/87 Currently, we have these packages: * ```Qml.Net.WindowBinaries``` * ```Qml.Net.LinuxBinaries``` * ```Qml.Net.OSXBinaries``` Each of these packages contains the entire Qt/QML runtime, as well as a lib required by Qml.Net to interoperate (```libQmlNet.so```). That means each build/release contains the entire Qt/QML runtime, even though the Qt version stays the same. I'm thinking of updating the above packages to *only* contain the ```libQmlNet.so``` needed for Qml.Net to work. The Qt/QML runtime will be dynamically downloaded and installed either at runtime, or during deployment. I will host the tarballs on GitHub. Each tarball will have a "version.txt" that will declare the Qt version. On startup of the app, if a Qt/QML runtime isn't detected, it will be downloaded. If you are deploying your app for production, chances are, you don't want users to dynamically download Qt/QML. Instead, you can download the archive yourself, and reference it via a ```QMLNET_QML_RUNTIME_LOCATION``` environment variable.

gitea-mirror closed this issue

2026-05-05 11:02:29 -06:00

gitea-mirror commented

2026-05-05 11:02:32 -06:00

Author

Owner

@pauldotknopf commented on GitHub (Dec 23, 2018):

Another option is to create additional NuGet packages, splitting the Qt/QML runtime and Qml.Net.

Qml.Net.WindowBinaries
Qml.Net.WindowBinariesQml
Qml.Net.LinuxBinaries
Qml.Net.LinuxBinariesQml
Qml.Net.OSXBinaries
Qml.Net.OSXBinariesQml

The *BinariesQml packages will rarely be updated.

@pauldotknopf commented on GitHub (Dec 23, 2018): Another option is to create additional NuGet packages, splitting the Qt/QML runtime and Qml.Net. * Qml.Net.WindowBinaries * Qml.Net.WindowBinariesQml * Qml.Net.LinuxBinaries * Qml.Net.LinuxBinariesQml * Qml.Net.OSXBinaries * Qml.Net.OSXBinariesQml The ```*BinariesQml``` packages will rarely be updated.

gitea-mirror commented

2026-05-05 11:02:35 -06:00

Author

Owner

@devmil commented on GitHub (Dec 23, 2018):

Yes! I really like that idea.
I think the second approach fits better in dotnet publish scenarios because it works out of the box and integrates nicely in the underlying Nuget mechanism.

@devmil commented on GitHub (Dec 23, 2018): Yes! I really like that idea. I think the second approach fits better in dotnet publish scenarios because it works out of the box and integrates nicely in the underlying Nuget mechanism.

gitea-mirror commented

2026-05-05 11:02:37 -06:00

Author

Owner

@pauldotknopf commented on GitHub (Dec 23, 2018):

My concerns with the NuGet package approach is:

How would libQmlNet.so find it's runtime dependencies? Currently, since they are in the same package, the Qt dependencies are easily found via rpath. Otherwise, I'd have to search for the Qt libs first, and then update LD_LIBRARY_PATH before PInvokeing libQmlNet.so.
Also, I need to know the exact path the QML directory is. Currently, I detected the loaded location of libQmlNet.so, and just poke around. If they are in another package, I won't have that ability. I'd have to somehow perform a DllImport("QtCore.dll") and then determine the path at runtime (like we currently do with libQmlNet.so.
Runtime-specific deployments. See issue https://github.com/qmlnet/qmlnet/issues/56. NuGet/dotnet likes to flatten the directory structure of the native libs in NuGet packages, which breaks Qt. Not puting them in Qt avoids this issue.

@pauldotknopf commented on GitHub (Dec 23, 2018): My concerns with the NuGet package approach is: 1. How would ```libQmlNet.so``` find it's runtime dependencies? Currently, since they are in the same package, the Qt dependencies are easily found via ```rpath```. Otherwise, I'd have to search for the Qt libs first, and then update ```LD_LIBRARY_PATH``` before ```PInvoke```ing ```libQmlNet.so```. 2. Also, I need to know the exact path the QML directory is. Currently, I detected the loaded location of ```libQmlNet.so```, and just poke around. If they are in another package, I won't have that ability. I'd have to somehow perform a ```DllImport("QtCore.dll")``` and then determine the path at runtime (like we currently do with ```libQmlNet.so```. 3. Runtime-specific deployments. See issue https://github.com/qmlnet/qmlnet/issues/56. NuGet/dotnet likes to flatten the directory structure of the native libs in NuGet packages, which breaks Qt. Not puting them in Qt avoids this issue.

gitea-mirror commented

2026-05-05 11:02:40 -06:00

Author

Owner

@pauldotknopf commented on GitHub (Apr 10, 2019):

I've created a repo that builds tar files for the Qt runtime for linux-64, win-64 and osx-64. Two tar balls are created for each, one for the runtime (no building/no header files) and another for dev (building).

https://github.com/qmlnet/qt-runtimes/releases/tag/releases

I'm thinking about adding another NuGet package that will help discovery/downloading/installing/configuring Qt runtimes. Something like Qml.Net.RuntimeManager.

The API would look something like this:

Qml.Net.RuntimeManager.Install(Qml.Net.Versions.RequiredRuntimeVersion);

The Qml.Net.Versions.RequiredRuntimeVersion would be baked into Qml.Net.

Implementors could add this line in their Program.Main, or use dotnet qml install to install it locally for packaging/distributing.

@pauldotknopf commented on GitHub (Apr 10, 2019): I've created a repo that builds tar files for the Qt runtime for linux-64, win-64 and osx-64. Two tar balls are created for each, one for the runtime (no building/no header files) and another for dev (building). https://github.com/qmlnet/qt-runtimes/releases/tag/releases I'm thinking about adding another NuGet package that will help discovery/downloading/installing/configuring Qt runtimes. Something like ```Qml.Net.RuntimeManager```. The API would look something like this: ```c# Qml.Net.RuntimeManager.Install(Qml.Net.Versions.RequiredRuntimeVersion); ``` The ```Qml.Net.Versions.RequiredRuntimeVersion``` would be baked into ```Qml.Net```. Implementors could add this line in their ```Program.Main```, or use ```dotnet qml install``` to install it locally for packaging/distributing.

gitea-mirror commented

2026-05-05 11:02:41 -06:00

Author

Owner

@pauldotknopf commented on GitHub (Apr 13, 2019):

Solves as of 0.8.0.

@pauldotknopf commented on GitHub (Apr 13, 2019): Solves as of ```0.8.0```.

gitea-mirror commented

2026-05-05 11:02:42 -06:00

Author

Owner

@vadi2 commented on GitHub (Jun 4, 2019):

I'm looking at deploying a Qml.Net app - it looks like QMLNET_QML_RUNTIME_LOCATION never made it in. What's the recommended way to deploy the binaries?

@vadi2 commented on GitHub (Jun 4, 2019): I'm looking at deploying a Qml.Net app - it looks like `QMLNET_QML_RUNTIME_LOCATION` never made it in. What's the recommended way to deploy the binaries?