I already mentioned this idea in “Simple Install” topic, but nobody answered. But I still think it will be a great idea to have boost and SDL libraries under version control. It will greatly simplify Windows and OS X setup because both this operating systems do not have built-in package managers. I know about MacPorts for OS X. But it really doesn’t work for vcmi. Because to build vcmi for xcode project generated by cmake you need a clang-build (with -std=libc++) version of Boost libs. And even after that it is a bad idea to link against MacPort’s SDL because it have install_name “/opt/local/lib/libSDL-1.2.0.dylib” and you will need this library at end-user machine at exactly same path. It’s obviously a bad idea to force people to install MacPorts for just playing (not developing) vcmi on OS X.
One more advantage is that everybody will link against the same library versions and there will be no need for everybody to recompile dependency libraries when upgrading to new version. So I’ll repeat once again that it is not a very big deal to setup everything using good step-by-step manuals. But I see no reason for this manuals to exist at all. Everything should be as simple as possible. It would be really nice to have “just checkout and build” setup sequence which is very friendly for new developers. As with idea to move to git I need only your agreement guys and can prepare patch (or pull request if we will move to github) myself.
Oops, this was intended to be in “Development” section.
I would rather avoid this:
- Most of “simple install” script\makefile\whatever will be platform-specific. In this case instructions should be better idea - we already have them for Win and Linux but OS X is still not covered.
- Huge amount of code (boost is huge) that we need to keep up-to-date. This may work for large projects but not for VCMI.
- At least on my system (Ubuntu) both SDL and boost are patched before packaging. Using original code from upstream may not work for some users.
Better option (IMO) is to write script specifically for Mac OS that will automatically download and compile required libraries.
You can’t make it platform-independent anyway - makefiles are not supported on Win, CMake should be installed first before you can use CMakeLists and there are no script language supported by both OS.
Maybe it is easier to link sdl\boost statically? Should be one-liner with cmake.
Players should not compile from source so location of library code won’t matter for them as long as game works.
I noticed that you already have some OSX-specific changes in source. Feel free to make patch for these changes.
First of all I should clarify that this proposal is Windows and OS X related. It is really impossible to handle all Linux distributions outside cause they vary a lot. And using svn-located prebuilt binaries insted of system ones installed by package manager looks really stupid because end-user package anyway will depend on this packages. But Windows and OS X are really different. Windows and OS X versions vary really little from version to version comparing to Linux. So it is possible to have prebuilt binaries for them to simplify setup. Please note that having prebuilt binaries under svn does not prohibit advanced users for linking with some unstable or patched library version built from source locally.
Any reason why instructions are better? Look at Windows setup manual:
- Download TortoiseSVN
- Install Visual Studio
- Checkout project
- Download SDL prebuild binaries
- Download Boost prebuild binaries
- Arrange folders specifically so Visual Studio project located in repo will work without modification.
- Build VCMI
Why I need all this steps if I can just checkout and build? If I am anyway downloading prebuilt binaries why they couldn’t be just downloaded automatically during checkout? If I need a specific folder structure why it couldn’t be “stored” in svn? Why we need to separately host prebuilt platform-specific binaries if they can be stored in svn? Why we need some sort of osx-downloader-script that will probably depend on wget (which is missing on OS X by default, so you will need to instal them). So setup instructions could be a better idea if they contained something that could not be automated. But VCMI instuctions aren’t such case 
So this is really annoying to do stupid-routine sequence. This may look OK for you because you had set everything up a long ago and now everything just works for you. But it is not just working for newcomers like me.
And regarding boost maybe someone keeping things up to date (which is as you say a hard work) is better than everybody doing the same locally? Why everybody should do the same work locally?
They are not ready yet. I want OSX setup to be: install cmake, install xcode, checkout sources, generate xcode project with cmake, build. Which can not be achieved without prebuilt binaries in svn 
P.S. FuzzyLite thirdparty library is already in trunk
Prebuilt binaries are fine. Not sure regarding placing binaries under VCS - right now most of binaries (graphics, release packages, Win libraries pack) are stored on vcmi.eu
But there is just too much source code. Compare numbers:
Latest boost source code (tar.gz): 64.7 Mb
VCMI 0.9 tarball: 1.4 Mb
Boost is almost 50 times larger than vcmi. This would greatly increase repo checkout time and size of repository on both server and local systems (unpacked it will be much more than 65 MB).
From Linux user point of view:
1, 2 - manual, most developers have them installed anyway
3 - definitely should be manual
4 and 5 - One Win-specific package with all binaries is fine. Don’t know why boost is not included - ask Tow if you’re interested.
But I’d rather keep this as separate download - why should Linux\Mac OS users download it as part of source?
6 - No clue… I can checkout repo and open CMakeLists with IDE to start coding - no need for manual project configuration.
I would need some manual steps to setup H3 data but that’s outside of svn directory anyway.
2 steps that may be possible to remove (that’s not up to me). Don’t know how this can be made more simple.
One question - how often you need to update libraries?
In last 4 years SDL made just 2 releases. And I think that VCMI is compatible with even older versions.
Boost 1.46 (which is still supported) was released around 1.5 years ago.
I think that OS upgrades (not counting Win 10-year old systems) are more frequent than need of library update.
So updating libraries once per year for every developer is easier than keep them updated whole time.
- Library is tiny even compared to SDL (200 kb-sized tarball)
- There are no prebuilt packages at all - only source. You can find packages with SDL and boost for both Win and Linux but in case of FuzzyLite all you have is source.
- It took me 10 minutes to write build system files for it. And library files are untouched ever since.
Of course 1-3 are manual steps the point was to remove 4-6. And 60mb repo increase? People are downloading gigs of games and movies nowadays so who cares that clean one-time checkout will be 5 min longer? And in reality whole time would not be longer because you will download this 60mb via browser anyway. And even disk size would be the same because boost would be stored on local system (and on server if we move it to package with SDL) anyway - in repo or separately. If you so care about disk space repo maybe even better - you can store binaries only for needed boost libs ignoring some useless for vcmi gigantic libs like Boost.Wave.
That’s all I want To be as simple as possible.
Are we still talking about storing boost sources in vcmi repo?
In this case it will be always stored on local system (because it will be part of source code) and it won’t be 50 Mb (archive) but 350 Mb (unpacked).
And svn checkout will be slow as hell after each boost update…
Since binaries are platform-specific you can ignore Windows package and make your own for Mac OS X which would be as simple as possible. Then write Mac OS how-to on our wiki along with link to your package.
I don’t see any reason to provide boost\sdl sources if we can provide precompiled libraries instead. Yes - somebody like you would still needs compile them first for their platform. But after that everyone will be able to get library and start coding.
You mayber misunderstood me, but my suggestion was to store under version control prebuilt binaries not sources. And headers of course. And regarding boost it is no differenece if it takes 350Mb on filesystem or 350Mb on filesystem in repo.
And that’s why we should move to git
Question why should Win\Linux users download Mac OS binaries (and vice versa) as part of source remains. Separate platform-specific download still sounds much better idea for me.
Plus in this way there won’t be any name conflicts.
What happens if Windows package in svn will be updated to newer version but Mac OS package is not updated yet? Library headers will be different but they will have same file names.
What if libraries itself have same names? This may happen for example with Win 32 bit + Win 64 bit packages.
Git may have a bit faster update but it still quite slow when you have 100+ of changed files.
Nay.
- My boost binaries are actually taking 2,25 GB (x86 and x64 count VC10 and VC11). Even when we drop support to VC10, it’s still way too big. Oh, but there should also be a binaries for OS X version for each compiler version that we support and is available on the OS X.
- Many C++ developers (like me) are using Boost in other projects than VCMI and have it in the filesystem (or in VC includes) anyway.
- You impose huge cost of downloading all the binaries every time Boost changes on all developers.
The general policy is to keep platform-specific downloads away from the repository. I prefer having one-time cost for the newcomers over the constant cost for all the developers.
I understand that it may be frustrating to perform additional steps when setting up VCMI build environment… but there will be much more frustration after (when you fight the bugs) anyway.
Boost is heavy, changes relatively often and depends on compiler version. Now my package works both for all VCs and MinGW. I’m lazy and there is already a page (boostpro) that provides prebuilt Boost for me.
You can’t assume that everyone has a fast broadband connection.
Besides, how long does it take to download an archive with libraries and extract it next to the trunk?
You’ll either impose significant cost of downloading Boost binaries on all developers (even if they already have them or use different OS) or end up introducing additional manual steps, that you were trying to remove.
Git won’t make our internet connections faster. It’s the transferred data volume that is a problem.
That’s not a problem. I just store them in separate folders. VC stores different include/libs paths for 32 and 64-bit versions.
but maybe put a project “windows dependencies” and “macintosh dependencies” on svn NEXT TO vcmi one, NOT inside it? this way things get separate for the reasons mentioned and exist in same SVN repo, so we only need to update libs when VCMI compilation complains they are too old, while get pros of SVN maintaining (i.e. update only binaries needed?).
2 gigs of boost libs? that’s insanely huge! are you sure it isn’t possible to pack there only needed part of boost? if sure I fully understand not putting them in svn (while local diskspace is not a problem under terabytes on HD, internet is another means - and it’s just libraries while it’s worth of half space of DVD).
Boost can be easily stripped to only needed libs. Look at github.com/RuntimeCompiledCPlus … dCPlusPlus project. It’s a nice example of what I ment. Clone and build! Only imagine building openal, boost, assimp, freetype, librocket, … It could take you a day to setup such a project. But in this case you can start diving into code in minutes.
And note that fresh cloning of RuntimeCompiledCPlusPlus 140Mb repo with 100+ files (boost included) took about a minute for me at 500Kb\s connection because actual transferred size is 36.62 Mb. And I really don’t get why people complain about 30Mb of only needed OS X binaries while having 2 gigs of boost windows binaries (or even more if compiling from source - remember all debug symbols and intermediate files)