-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Dedupe libvips-42.dll for windows users #3402
Comments
At The logic for this Windows-specific behaviour is in https://github.com/lovell/sharp/blob/main/install/dll-copy.js There used to be (permission?) problems in the past with Node.js and symlinks on Windows, but perhaps we could experiment using a "junction" for this? |
how long ago are we talking? Because windows has two types of symlinks - junctions, which generally need admin rights to create, and "plain symlinks" which don't. |
My Windows knowledge is rather limited, but my understanding is that junctions can be created by a local, non-elevated user, but symlinks might require local admin rights, at least on NTFS. Sadly "junctions" won't help here as they are for directories only, where we are dealing with individual files. (The fix for the Node.js ecosystem was via libuv/libuv#1706 and has been available since version 10.) If we are to use symlinking, it would be best to retain the copying logic as a fallback should it fail. |
In that case I guess the question is "why does the vendor directory need to hang around?". The dll files are not tied to Node version, so making the node-gyp process look for them in the |
When We could test for |
never tried anything gyp related (other than filing issues to please add python 3 support back in the 2.7 days =) but I can have a look? |
How will removing these duplicate files interact with prebuild-install? It is not uncommon for prebuild-install to be run each time an electron build is produced. |
@Julusian I think it will be OK as Perhaps, as part of this proposal, we should also add logic to |
This will probably be superseded by #3750 |
This problem has gone away with the release of sharp v0.33.0 - all that custom download and file copying logic has been removed. |
Feature request
As Windows doesn't come with libvips, Sharp convenient bundles it in as a .dll file, but it bundles it in twice: once in
build/release
and then again invendor/8.13.2/win32-x64/lib
. Given that it's a whopping 21Mb, deduplicating that would be an excellent idea. (The same applies tolibglib-2.0-0.dll
,libvips-cpp.dll
, andlibgobject-2.0-0.dll
, which take up a combined additional 2Mb)The two most obvious options I can think of would be:
vendor
dir from the Windows build before packing up the release, orbuild/release
Windows symlinks instead of real files.Either would cut the Windows release size in half.
The text was updated successfully, but these errors were encountered: