tauri-apps / tauri

Build smaller, faster, and more secure desktop and mobile applications with a web frontend.
https://tauri.app
Apache License 2.0
82.76k stars 2.48k forks source link

[feat] platform/arch-specific resources #8501

Open zhangsan946 opened 9 months ago

zhangsan946 commented 9 months ago

Describe the problem

In additional to executable files, static/dynamic library files are also platform & arch dependent. Need a way to embed external binaries for other extentions such as: .dll, .so, beside executable files.

Describe the solution you'd like

Support externalBin setup as following:

"externalBin": [
    "binaries/my-sidecar"
]

And in additional:

"externalBin": [
    {path: "binaries/my-sidecar-dll", ext: "dll"}
]

Alternatives considered

No response

Additional context

No response

FabianLars commented 9 months ago

I'd say the resources feature is what you're asking for https://tauri.app/v1/guides/building/resources/. They can be platform specific via https://tauri.app/v1/api/config#platform-specific-configuration.

Your pr also only works on windows because linux and macos typically don't have library files next to executables.

FabianLars commented 9 months ago

whoops, didn't mean to close this before you have a chance to respond

zhangsan946 commented 9 months ago

Hi @FabianLars, thanks for the reponse. The resource feature won't help bescause the library file is also arch dependent like the excutable file. Please take the wintun.dll file as an example https://www.wintun.net/builds/wintun-0.14.1.zip. It has to keep the name of wintun.dll and it has different version for x86, amd64, arm.. unless resource feature could be not only platform specific but also arch specific. On linux, library search path is LD_LIBRARY_PATH specified path, executable's rpath, /lib folder. User could set the LD_LIBRARY_PATH if the executable's rpath is not set to be the same folder to executables.

FabianLars commented 9 months ago

The resource feature won't help bescause the library file is also arch dependent like the excutable file

right, maybe we could expand the platform specific configs to also be arch specific (optionally) but i can't think of a different usecase than this issue so maybe that's a bit too much. Using the --config/-c flag works but having to use a manual step for this feels awkward too.

On linux, library search path is LD_LIBRARY_PATH specified path, executable's rpath, /lib folder. User could set the LD_LIBRARY_PATH if the executable's rpath is not set to be the same folder to executables.

That's why i said your solution doesn't work. In the .deb bundle the sidecars will be installed into /usr/bin where .so files don't belong. In the .appimage bundle the rpath and iirc the ld_library_path are set but either way appimages also have an internal /usr/bin/ folder where it wouldn't be as bad to have .so files in but still unusual.


So yes, i agree that we need something but i also think it needs a bit more thinking. Abusing the externalBin/sidecar config for this doesn't seem right.

minht11 commented 3 months ago

I have use case for this. I am building Windows only application on a Mac (ironic I know). UI does not need native lib, so I could build myself abstraction which calls sidecar only when on Windows and still works for most other stuff on other platforms. Right now that is not possible.

Allowing platforms to be optional would be great.

FabianLars commented 3 months ago

@minht11 Your use-case sounds like it's already possible: https://tauri.app/v1/api/config#platform-specific-configuration

This issue here is about specific configs for platform+architecture combinations, so for example different configs for windows-x86_64 and windows-aarch64. If you only build the app for windows x64 (so like 99% of windows users) the current system should work fine.