When one writes an open-source project and uses Google Code or GitHub, and wants to use a library like Lua, how should one do this?

  • Should the dependency be included in the repository?
  • Should the dependency be built from within the same build script as the rest of the project, or from a separate build script?

Given that the library doesn't need installation before compilation.

5 Answers 5


I would highly recommend reading through Git's documentation on submodules; it addresses this very problem, assuming that all of your sources use Git. If they don't, you can always set up a git repo for the purpose of integration. The effort is trivial, and the payoff is significant.

  • 1
    Submodules is rather weak implementation of dependency-management in common and in Git. At least git subtree is a lot better iteration Jan 21, 2013 at 6:18
  • 6
    -1 Please include details of the link in your answer otherwise the answer is useless when the link disappears - as is the case now. Unfortunately, I don't have the rep to downvote, yet
    – Precastic
    Oct 20, 2014 at 7:13
  • @Precastic: If you google the link text, it takes you straight to the new page; I'm not sure how much more informative that can be.
    – Bryan Agee
    Oct 21, 2014 at 2:46
  • 2
    Please read stackoverflow.com/help/how-to-answer - specifically the section titled "Provide context for links" (quote: "Always quote the most relevant part of an important link, in case the target site is unreachable or goes permanently offline.")
    – Precastic
    Oct 21, 2014 at 9:19

Should the dependency be included in the repository?

I think dependencies should always be included in the repository as long as including them does not violate any terms of use. Few things are more annoying than having to find the right versions of the right dependencies manually before you can make a build. Sure, this is easy when you have automated tools to do this for you, which can find and download the right dependency, but what if you aren't connected to the web at the moment or the server is down or the project of the dependency has been discontinued completely and taken offline? Always include the dependencies if possible.

Should the dependency be built from within the same build script as the rest of the project, or from a separate build script?

Unless there's a good reason to compile from source, use precompiled versions.

And why not provide options in the build script? A simple switch to choose whether the dependencies should also be compiled or not. If the user chooses to compile the dependencies as well, then just invoke their very own build scripts from your product's build script. So the user can invoke the dependcies' build scripts manually or choose to create a full build of everything. But I'd just deliver the dependencies as binaries if there's not a good reason to compile them from the sources. I think in the Open Source world, some licenses require you to distribute the sources along with your product but that does not mean you can't have them precompiled.

In short: Provide a whole standalone, working package if possible. This will provide the most convenience to your users.

  • 1
    @tdammers: I know, if your installing software on a linux system the package manager does all the work for you. But that requires an internet connection and the package must be in a certain format and I explicitly stated that automation tools can help with this. You can't use such a system for .NET open source tools, for example. If you take a look at sourceforge tools like NHibernate or Castle Windsor, then you'll see that all dependencies are inlcuded as binaries. And that's the only reasonable thing to do.
    – Falcon
    Sep 23, 2011 at 8:14
  • 1
    @tdammers: Conincidentally, I have to install the OpenOffice SDK on a linux machine here today. Since the SDK cannot be installed via the package manager, I grabbed the RPM from the website. What do you think is the first message I get when trying to run "rpm --install" ? error: Failed dependencies: ooobasis3.3-core01 is needed by ooobasis3.3-sdk-3.3.0-9567.x86_64 - OH JOY!
    – Falcon
    Sep 23, 2011 at 9:16
  • 2
    @tdammers: you're right, but in the case I'd love to have this redundancy if only setup and installation was easy. And when you want to see a dependency hell, take a look at a /usr/lib directory. There's everything: redundance, subversions and you don't even know which program uses which libs. Sure, let the package manager handle it! But what if the package manager can't handle it like in the open office case I mentioned. That basically means you're screwed and you'll have a hard time installing something.
    – Falcon
    Sep 24, 2011 at 7:48
  • 2
    @tdammers: And the more I think about this and my experiences: I cannot even count the times I had to create symlinks in this directory just because dependencies failed or some program refused to run, even when installed via a package manager. Maybe the situation has become better now, but it's often still just hard work to get some things to run. Problems that could've been avoided if they just had shipped the dependency with the application. I'll gladly pay the few MB of additional space just to avoid that hassle.
    – Falcon
    Sep 24, 2011 at 8:07
  • 2
    @tdammers: The countless tutorials on the web on how to install a specific program on a specific linux system are witnesses to this issue.
    – Falcon
    Sep 24, 2011 at 8:11

This may or may not apply to your use case, but what we do at work is include a "References" folder in each branch. We place 3rd party DLLs in here. This causes a lot of duplication of relatively unchanging binaries in source control, but storage is cheap and at any point each branch & tag has exactly the dependencies (and version!) it's expecting.

We pre-compile the dependencies ourselves and move the compiled binaries into that folder. Our own in-house shared library is treated this way as well. That way the same technique works for pre-compiled proprietary libraries, open-source libraries, and in-house libraries.

As far as actually answering your question now that I've re-read it, do the same thing, and just mention that your project uses a precompiled 1.3.5 version of Lua.


Should the dependency be included in the repository?

It can be referenced in repository (by any usable for SCM method), if this dependency is integral part of product (source-dependence), not binary-dependence, which can be resolved separately

Should the dependency be built from within the same build script as the rest of the project, or from a separate build script?

Doesn't matter at all. You can prefer any method, according to your requirements (speed/transparency/manageability/etc)


Being an Eclipse shop, we have just started using Buckminster to manage our build/assemble/deploy process.

Our first stage has been to pull out all of our existing dependent libraries and let buckminster take care of materialising the correct ones. This makes for a much quicker and smaller deployment.

The next step will to move our monolithic svn repository to a series of modular git repositories.

I don't know how well buckminster would integrate with git submodules (or mercurial subrepos for that matter), but it is nice that buckminster is agnostic with regard to the VCS used for any given component.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.