Wrong comit

[BigJoe01]

I trying download or clone but file is very big.

[Luke1410]

The repository contains the complete 0.1.0 release including the prebuild Visual Studio libraries. We provide alternative downloads either via our main SVN repository at https://www.slikesoft.com/svn/slikenet (where you can exclude the prebuild-directory from being checked-out) or download archives on our webpage: https://www.slikesoft.com/?page_id=1236&lang=en

There we also provide plain source code downloads (without the prebuild libs) which are only 30-50 MiB in size.

I tested cloning the GitHub repository locally on a rather slow connection (around 6-7 MBit/s downstream) which took roughly 1h.

Is this working for you?

[OvermindDL1]

The repository contains the complete 0.1.0 release including the prebuild Visual Studio libraries.

Good frick, Never put large binary blobs in Git, ever! It will significantly hamper Git performance! If you add big files to github then use GitLFS (built in to github as well) or just store them as a package offset that the user can download separately (or a makefile can auto-download), but never ever ever put big binary blobs in a git as it can pretty well permanently damage the repo!

[OvermindDL1]

You really need to purge those from the history and force push to rebuild the history on github or this will never work well and will get progressively worse over time (even worse than the 1hr+ clone times it has now!).

Never ever put binary blobs in a git repo (and more importantly, why ever put a single OS's binary blobs into a repo?!?).

[Luke1410]

Looks like things take up pace faster than we had expected. We certainly planned to move the larger binaries over to GitLFS (basically following the process depicted here [1]) in a few days. But since it seems to be more pressing, we'll prioritize this now (internal case number: SLSOFT-17). So I'm glad you brought this up here.

For the reasoning on why putting single OS's binary blobs into a repo (or better said: into the release package): Especially on Windows and for new developers we want to set the hurdle to get started with using SLikeNet as low as possible. While building libraries from source is something almost every developer gets accustomed to on Linux and OSX quite early, on Windows my experience taught me otherwise. Therefore, we decided to include prebuilt libraries for the supported VS versions in the first version already and are reviewing the situation for Linux/OSX later. Understand that this is just the reasoning for having the files contained in the release packages. The decision for putting them into the source repository was basically made so to have all sources of our releases (i.e. SVN repository, GitHub, download archives on the webpage) being consistent content wise. I'd be certainly interested to learn your opinion on this decision.

[1] https://help.github.com/articles/moving-a-file-in-your-repository-to-git-large-file-storage/

[OvermindDL1]

I would absolutely not put source binaries in the repo at all. Having them as a linked to zip of them is fine, but they should never exist in a source repository.

Also I think you do not give Windows developers enough credit. Compiling is not at all a hard thing. Heck, using something like hunter makes it trivial even for Windows dev's.

But still, the binary blobs need to be removed from git history. I'm usually never a fan of editing history (ever really) but this really needs to be done or this repo will become near unusable forever on.

[OvermindDL1]

Also, mac/linux dev's really do not want to be polluting their workspace with Windows files, just like windows dev's don't want to pollute their workspace with *.so files or so.

[Luke1410]

Thanks to your input we reconsidered our approach here. As announced, we removed the Lib/prebuild directory from the GitHub repository. This has been done and the GitHub repository now only contains the source code and documentation (which corresponds to the source-only packages provided for the releases on our download page at: https://www.slikesoft.com/?page_id=1236&lang=en ).

We also revised our intend to use GitLFS for storing the library files and diverted from this idea with the main reason being that we basically agree with you on the point that this would contradict the normal Git(Hub) workflow (nobody who clones the SLikeNet repository should be bothered with hundreds of MB of Windows binary library files). And in order to be completely transparent on the decision making process: The fact that we likely would have to get a monthly subscription which increases over time significantly, accounted to that decision too.

Instead, we actually go with the alternative approach which you also mentioned and will provide additional download packages on the Release page on GitHub which developers who are interested in can download (optionally). Since the upload is gonna take a while this is likely to take a day or two. For the time being the packages can be downloaded directly from our webpage (same link mentioned above).

---

On the topic of providing Windows libraries in the package: Maybe my point didn't come through just right here. I certainly didn't want to suggest that Windows developers are incapable of dealing with source code releases and build binaries/libraries from source. I'm quite sure that any developer who has more than one or two years programming experience (be it on Windows, Linux, Apple or whatever) is quite capable of building 3rd-party libraries. My point is merely that (in my own experience) when making your first steps with development/programming on Linux you quite easily get to the point where you (have to) start building dependencies from source code and this becomes quite a familiar workflow for you. In the Windows world there are a lot of libraries which are providing prebuild binaries. Even in the open source community (to name just a few examples: boost, OpenSSL, OpenAL, etc.). On the commercial side all the library providers I can think of (especially in the games industry) are shipping their products with prebuild Windows libraries as well (f.e. FMod, EmotionFX, Steamworks, etc.) - even in cases where they provide you with the source code. So that said: I think it's quite usual to provide Windows binaries and doing so can actually safe you as a developer time (new release -> just copy over the headers and libraries and you are done --- no need to rebuild the library and bother with possible build environment induced problems which I guess all of us ran into at one point or the other).

[OvermindDL1]

As announced, we removed the Lib/prebuild directory from the GitHub repository. This has been done and the GitHub repository now only contains the source code and documentation

That is awesome, it now downloaded in a few seconds, a far cry from 1+ hours. Thanks much!!! It looks like OP's issue here can be closed. :-)

On another note of building on windows, even pre-distributed libraries I was almost never able to use (back when I used windows) because they always built them with certain settings that was incompatible with what I was needing to compile for. Are you building binaries for each of the dozen or so combinations of incompatible VC settings or what are the defaults you use?

I'd really recommend using some kind of dependency management system. The Hunter that I linked prior is fairly common in the C++ world and works on all platforms that RakNet does (and more) and is pretty well drop-in-and-use friendly if you want user-friendly (plus you could even pre-generate windows VC solutions from it if you wish).

[BigJoe01]

Thx

[Luke1410]

Sounds like this satisfies your request @BigJoe01 . Hence closing the issue now.

@OvermindDL1 On the note on pre-distributed libraries: Certainly it's more than a valid point that there are dozens of configuration combinations and we won't be able to (and we don't even want to :) ) ship prebuilds for all of them. We are trying to satisfy the combinations/configurations which we think are the most common/default ones. If someone uses SLikeNet and realizes that one of the provided configurations isn't suitable for his needs, he can always get in touch with us. We'll consider then whether it's reasonable to add his required configuration to the set of provided prebuilds (maybe replacing/superseding a previous (unused) prebuild). Or provide him with prebuilds for his particular need so he can be sure we vouch for the correctness of the built library.

Atm we ship a set of 72 prebuilds (that is 72 for each VS version). Chapter 3.2.3 in the readme goes into the details. 24 are provided for the RakNet compatibility mode and 48 are SLikeNet prebuilds. In principle it's a combination of [32|64 bit] X [Debug|Release|Retail configuration] X [DLL|Static] X [Unicode|ASCII] X [basic|extended feature set] (where for the RakNet compatibility mode we drop the Unicode version). The RakNet compatibility mode is currently planned to be dropped in SLikeNet 2.0.0 (so that latest then 24 combinations will be dropped - internal case number SLNET-109). We are also working on removing the need for different libraries based on the used feature sets (that too will then get rid of 24 combinations - internal case number SLNET-110).

Utilizing dependency management systems is also already on our radar for the shorter term improvements, though hunter wasn't on that list yet. I've added it now to investigate (internal case number: SLNET-111).

I think this whole thing is getting a bit off topic here though. If you like, move it over to a thread in our forum to continue discussing it there (no need to create an account there, if you don't want to --- you can also post without creating one): https://www.slikesoft.com/forum/