Handling dependencies when creating libraries (git)

Anton · 2010-09-09 14:52:13

Ok I wrote a huge post which was lost, so I'll try to be brief this time.

I'm making a library, and a wrapper/binding for that library in another repository. The wrapper obviously depends on the library. So my question is, how can I relate these repositories? At first I thought I could have wrapper repo include the library repo as a git submodule. But the main drawback of that is that if I then create a second wrapper for the library in a third repo, also including the library repo as a git submodule, I will get two copies of the library repo if I make a project depending on both wrappers.

I'm starting to think that maybe I should just have my wrappers assume that the library is already installed in the system, and look for it in system paths. And I'm not used to creating install scripts at all, but that's another topic. I haven't been developing in a linux based os very long. But my fear then is when I need to use different versions/branches of the library, and will have to remember to run the correct install script and stuff manually.

Please advice. How does your workflow look? Are there any tools worth mentioning? So far I have been using git for version control and scons for building and that's it. Real world examples that I can browse on github or such might be helpful too.

Thank you.

cmtptr · 2010-09-09 23:47:27

Is there any reason why the library and the wrapper can't be maintained in the same repository? For something that needs to be so closely correlated as you described, it seems like it would make more sense to me, and plus I believe it better fits the git philosophy of managing snapshots of an entire project rather than files.

Anton · 2010-09-10 07:53:35

I somewhat like the idea of having them maintained in the same repository, since it would be easier to handle build and deploy/install. But I also think it would be nice if the library and wrappers had separate histories. And also, I'm sure I've read somewhere that git repositories are supposed to be small, so then I feel encouraged to split projects into separate repositories whenever it feels natural (like when I'm creating a new layer on top of an existing module, and there is a one-way dependency). Thank you for the advice, I will consider it some more and read up a little on the git philosophy and repo size.

fsckd · 2010-09-10 09:17:57

Take a look at submodules.

Anton · 2010-09-10 10:49:23

I do like the git submodules, but there is a potential problem with them. When working with reusable components, it's very tempting to include them as git submodules. But, I'm not sure how to handle a situation like this:

(ReusableA)<----\
        Î        \
        |         \
(ReusableB)       (ReusableC)
        Î          Î
        |         /
(Application1)--/

Application1 depends on ReusableB and ReusableC, and therefore includes them in it's repo as git submodules. However, since both ReusableB and ReusableC depend on ReusableA and include that as git submodules, I end up with two copies (of possibly different revisions) of ReusableA. This is the problem that I'm not sure how to tackle. Maybe it will be easy to avoid by just not initializing both instances of ReusableA. So is this a situation to avoid or am I just worrying about a problem that isn't really a problem? If it's possible to only initialize one instance of ReusableA, all involved repositories will still have clear dependencies in form of git submodules.

tavianator · 2010-09-10 17:42:04

Reminds me of virtual inheritance in C++. I'm not sure if there's an equivalent in git.

awkwood · 2010-09-10 18:12:24

A similar question/scenario is answered here:
http://stackoverflow.com/questions/1419 … pendencies

I still think submodules are the best way to handle your dependencies, especially if you're already using git for version control.

Anton · 2010-09-10 21:43:05

tavianator: It seems as if the closest thing to virtual inheritance is including ReusableA as a submodule directly under Application1 and have the build script use that instead of the other instances of ReusableA. (Based on awkwood's answer as well as a question I posted on stackoverflow).

Thank you all, I think I know how to continue now.

Arch Linux

#1 2010-09-09 14:52:13

Handling dependencies when creating libraries (git)

#2 2010-09-09 23:47:27

Re: Handling dependencies when creating libraries (git)

#3 2010-09-10 07:53:35

Re: Handling dependencies when creating libraries (git)

#4 2010-09-10 09:17:57

Re: Handling dependencies when creating libraries (git)

#5 2010-09-10 10:49:23

Re: Handling dependencies when creating libraries (git)

#6 2010-09-10 17:42:04

Re: Handling dependencies when creating libraries (git)

#7 2010-09-10 18:12:24

Re: Handling dependencies when creating libraries (git)

#8 2010-09-10 21:43:05

Re: Handling dependencies when creating libraries (git)

Board footer