fasterthanlime
commented
5 years ago tl;dr What you describe is not the ideal case, but there's a flag for that.
Linux builds tend to have symlinks from libfoobar.so to libfoobar.so.2 to libfoobar.so.2.14. Dereferencing those would result in unnecessary copies.
macOS builds often have a lot more symlinks (entire frameworks). Again, dereferencing those would easily result in 1.5x larger builds.
So, no, the ideal case is what butler has always been doing, which is to reproduce exactly what you tell it to (symlinks and all).
That said, dereferencing symlinks has been requested before, so you can use --dereference.
I still think it's a bad idea: I think you should have on disk exactly what users are going to have on disk. If that means copying files every time, then so be it.
On the other hand, I do think content channels are a good idea, and I want to support them in the app at some point. Those are different though. You wouldn't need to turn on dereference there, just to push the "runtime" (with symlinks) part and the "content" part to separate channels. But that's for some time in the future!
aaronfranke
dos1
I have a "Content" folder that I wish to distribute with the game. I'd like to only keep one copy of this in my game's folder, so I tried symlinking to it from the builds folder (
ln -s). Unfortunately, Butler does not follow symlinks, it simply uploaded an empty file of some sort.After I added a symlink to Content, this is what Butler's log says:
And the resulting ZIP file has an entry called "Content" which is 13 bytes and says it was modified in 31 December 1969. Ideally, instead of this, Butler would follow the symlink and treat the folder as if it was actually there and make it part of the upload.