-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Actually installing DLLs via @[Link]
#13858
Comments
So how does your proposal work for system dlls? I'm not sure I understand the alternative Zig-like proposal, why is the dll_path in charge of the lib user? I'll invoke @oprypin to weigh in. |
It doesn't, and not all of those DLLs are even redistributable.
This is not 100% necessary here, |
I personally don't find it hard to just copy some files in my own way. Users of other programming languages also need to do it. Automatic copying can be slightly unexpected but if it's opt-in then great! 👍 |
They will just use the same If |
There is no correlation between a DLL's name and its import library's name. Using stdlib's dependencies as example:
Reconciling the two sets of names means either rebuilding the DLLs, or giving the import libraries different names from non-Windows platforms. IMO neither option is desirable. And not doing this means the DLL names must be supplied somewhere, which is what
Yes, the meaning of |
One practical problem is @[Link("z")]
{% if flag?(:win32) && compare_versions(Crystal::VERSION, "1.11.0-dev") >= 0 %}
@[Link(dll: "zlib1.dll")]
{% end %}
lib LibZ
end or like this: @[Link("z")]
{% if flag?(:win32) && flag?(:supports_link_dll) %}
@[Link(dll: "zlib1.dll")]
{% end %}
lib LibZ
end where |
I don't think this practical problem is a big issue. Stdlib and compiler version are usually expected to be equal. So there's not much to worry about for stdlib, yet it's easy to integrate safe guards. IMO |
There is another caveat: if the local compiler is statically built, even from a compiler with support for I guess we could add |
To facilitate load-time dynamic linking on Windows, Crystal added experimental compiler support to detect and load DLLs from more "convenient" locations via a delay-load helper, but it does not work on DLLs that import data. So let's try to actually install them instead.
To get a better idea about how other compiled languages handle this, here are some examples with SDL2:
install(TARGET_RUNTIME_DLLS)
.installBinFile
, which can install files other than DLLs too. Presumably, this link step is automatically executed when building projects that depend on the given SDL2 bindings.I propose adding a new
dll
parameter to the@[Link]
compiler annotation:dll
must be a string literal or an array literal of them. Each string on a lib indicates the name of a DLL that should be searched and installed. When building on Windows and not cross-compiling, the compiler either hardlinks or copies the DLLs to the same directory as the built executable. The search order used by the compiler, completely independent from the runtime DLL search order, would be:CRYSTAL_LIBRARY_PATH
%PATH%
There is no longer automatic DLL detection from import libraries, and all libraries must declare their DLLs manually. This is because we only want to install library DLLs, not system DLLs like
kernel32.dll
orvcruntime140.dll
, but no detection scheme is ever going to handle that. Hence, this proposal effectively reverts all the delay-load stuffs added in recent Crystal versions.Alternatively, if we go down the Zig route of supporting arbitrary file installs, we could spare a new annotation:
Of course, this further blurs the line between Crystal as a compiler and Crystal as a build system, in absence of an actual build system tailor-made for Crystal.
The text was updated successfully, but these errors were encountered: