Open zhangsan946 opened 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.
whoops, didn't mean to close this before you have a chance to respond
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.
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.
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.
@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.
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:
And in additional:
Alternatives considered
No response
Additional context
No response