Open xorgy opened 9 years ago
Understood, and I don't intend to use git commits to track executables. The current intention is to keep the longstanding Khronos location (see link at the beginning of the Readme) to hold the binaries. This should be where folks wanting a binary are steered. The recent git commit for executables was an exception, and I might rather delete that part of the repository, if that's possible.
Up to date binaries are now at Khronos.
I would very much like to see the binaries pulled out. I spent almost an entire day a week ago trying to figure out why Install/Linux/glslangValidator was stuck at rev. 30 even though I was rebuilding against newer sources. Turns out, my build was somewhere else entirely and Install/Linux/glslangValidator was a red herring.
@jekstrand, agreed. Commit ebb7bf37fd4681dd33e6dabdb3401187f7eef59f removes them. @xorgy, leaving issue open for future use of GitHub Releases. (They are currently hosted by Khronos.)
Thank you, and welcome back. :-)
Git is very fast and efficient for tracking line-oriented text files, however it is fairly weak at working with binaries. The common case is that git will rewrite the entire binary file, and both will need to be downloaded with the repository, making Git clones(and some other operations) slower than they need to be. It will get far slower over time if binaries are updated in the repository more and more times.
Github has a mechanism for releasing binaries. It's pretty convenient and makes it simple for people to pick up older releases if the need may arise. It also allows you to do pre-releases, which people are not encouraged to use in a production setting, but can try out nonetheless.
Another benefit of this, is that in the future the build process can be automated and releases can be updated every time you push a release tag.