4

I'm looking for some insight on how to handle git repositories that each utilize a (large) static library, and have some concerns about a solution I thought about.

Suppose lots of separate projects, all under version control, each rely upon a large static library that is under (very) active development. Let's say that repos A, B, C, ... all have their own development teams, and they all rely on lib. Now, the lib project itself is under version control, and is also being worked on by yet another team. Let's assume that some teams can't/shouldn't access the source for lib, but accessing the headers and static library binaries is OK.

Now, when I first thought about how to organize this sort of situation in git repos, submodules immediately came to mind. Here's a quick diagram:

"lib" repo:
    Dist/ -> "lib_dist" submodule
    Headers/
    Sources/
    ...

"lib_dist" repo:
    Binaries/ (output from "lib" repo build process)
    Headers/ (copied from "lib" repo in its build script)

"A" repo:
    Headers/
    Libs/
        lib_dist/ -> "lib_dist" submodule
    Sources/

"B" repo:
    (looks just like "A")

"C" repo:
    (again looks like "A")

The build process for lib would compile the source into static library files and copy the headers to the Dist subfolder. This subfolder is a submodule of the lib repo, and we'll call it the lib_dist repo. This lib_dist repo could then be added to A, B, C, ... as a submodule.

Advantages: Developers on the teams for A, B, C, etc. would not have to compile this large static library themselves, can't see the source code for lib, and the A, B, C, repos will always be able to compile no matter which revision a developer is using. What I mean is that if a developer on project A needs to go back to an older revision, they can simply git checkout <rev_hash> . and then git submodule update; even if lib_dist has changed since the time <rev_hash> was committed, the submodule revision will be adjusted to match the one present at the time <rev_hash> was made. This means the lib_dist headers and binaries will "just work".

Disadvantages: Over time (and exacerbated due to active development), the lib_dist repo will grow very large, as git really isn't meant to store binary files under version control. Git repos over 1GB in size can really tax a server, and pushing/pulling will become very time consuming and resource intensive.

So, in this sort of context, what are the "best practices"? Is git even the right tool? Does a better tool exist (I'm open to other version control tools)? Nothing really came to mind for me, short of manually managing lib versions. But, it seems to me that manually managing the to-be-compiled-against version of a static lib is so... 20th century (and error-prone).

Thanks!

EDIT: I should add that these projects are written in C/C++.

inspector-g
  • 4,146
  • 2
  • 24
  • 33

1 Answers1

0

I would not recommend using git for managing the library binaries, as gits core feature is versioning which is not what you need. Also if you are building on multiple platforms, you would have to provide separate binaries for each platform.

What you are really looking for seems to be some kind of automated dependency management as e.g. Maven for Java.

wonce
  • 1,893
  • 12
  • 18
  • I just read a bit about Maven, and it appears quite extensive so obviously I haven't wrapped my head around all of it. Nonetheless, something like it's dependency management sounds about right for our needs, but these projects are written in C/C++. – inspector-g Jan 31 '14 at 18:34
  • You might want to take a look at http://stackoverflow.com/questions/1136065/maven-like-dependency-management-for-c – wonce Jan 31 '14 at 18:45