I have a project that is built for several OS (Linux and Windows at the moment, perhaps OS X) and processors. For this project, I have several library dependencies that are manly external, but I have a couple of internal, in the original form, which I will compile (cross-compile) for each combination of OS processors in my context.
Most external libraries do not change very often, perhaps in the case of a local fix or some \ bugfix function implemented in a newer version, I think that this can benefit the project. Internal libraries change quite often (1 month) and are provided by another team in my company in binary form, although I also have access to the source code, and if I need to fix the error, I can do this and generate new binaries for my use before next release cycle. Now I have the following setting (file system only):
-- dependencies | -- library_A_v1.0 | --include | --lib | -- library_A_v1.2 | --include | --lib | -- library_B | --include | --lib | ...
Libraries are stored on the server, and every time I do an update, I need to copy any new binaries and header files on the server. Client-side synchronization is performed using the file synchronization utility. Of course, any updates for libraries should be announced to other developers, and everyone should remember to synchronize their dependency folder.
Needless to say, I don't really like this scheme. So I was thinking about putting my libraries under version control (GIT). Build them, pack them in tgz \ zip and click on repo. Each library will have its own git repository, so that I can easily mark the \ branch of already used versions and test disks with new versions. A "stream" of data for each library that I could easily get, merge, update. I would like to have the following:
get rid of this normal file system for storing libraries; right now, full separate folders are stored and managed for each OS and each version, and sometimes they are not synchronized, which leads to a mess
more control over it, in order to have a clear history about which versions of libs we used for which version of our project; what can we get from git (VCS) with our source code
be able to tag \ the branch of the dependency version that I use (for each of them); I have my own tag / branch v2.0.0 for library_A, from which I usually get it for my project, but I would like to test the version 2.1.0 disk, so I just create it, click on the server in another branch and call my build script with this particular dependency pointing to a new branch
have simpler build scripts - just pull the sources from the server, pull the dependencies and build; which would also allow using different versions of the same library for different combinations of processors and OS (more than we need it)
I tried to find alternatives to a straightforward git solution, but without much success - for example, git-annex , which looks too complicated for what I'm trying to do.
What I am facing right now is the fact that there seems to be a very strong opinion regarding placing binaries under git or any VCS (although technically I would also have header files, I could also format the folder structure, which I described directly on git so as not to have tgz \ zip, but I would still have the binaries of the libraries), and some of my colleagues, guided by this common belief, oppose this scheme of things. I understand perfectly that git tracks content, not files , but to some extent I will track content as well, and I believe that this will definitely be an improvement over the existing scheme of things that we have now.
What would be the best solution to this situation? Do you know any alternatives to git based things scheme (VCS)? Would such a monstrous thing have my circuit under git :)? Please share your opinions and especially with experience with these situations.
thanks