Re: Project- vs. Package-Level Branching in Git

From: David Aguilar <davvid@gmail.com>
Date: Jan 29, 2011, 23:28 UTC
Message-ID: <20110129232848.GC7676@gmail.com>
In-Reply-To: <20110129194258.GE602@nibiru.local>

On Sat, Jan 29, 2011 at 08:42:59PM +0100, Enrico Weigelt wrote:

Show 20 quoted lines

> * Jakub Narebski <jnareb@gmail.com> wrote:
> 
> > That is only if lib{a,b,c} is _internal_ dependency.  In usual case
> > project A might depend on library B *to be installed*, but it doesn't
> > mean that source code of library B has to be in repository for project
> > A.  And in usual case when project A depends on library B, it relies
> > on library B public stable API (its build system might check if you
> > have new enough library B installed).  If you depend on specific
> > version of library, patched, that is your problem...
> 
> To make it more clear: 
> 
> At buildtime, a _package_ (not project!) "A" requires a already built
> and installed package B in some sane place where the toolchain can find it.
> On deployment of package "A", it has to be made sure that package "B"
> is also deployed (eg. by a dependency-handling package manager).
> 
> These are two entirely separate stages in a software's lifecycle.
> Buildtime and deployment dependencies may be different (even deployment
> and runtime deps may differ).

This is exactly how we do it at my workplace. We have literally hundreds of individual git repositories. Naturally, some packages depend on others and the only "trick" is building them in the correct dependency order. A simple dependency tree handles this for us.

We use same-named branches across several repos when coordinating features across many projects. e.g. we had an "el6" branch when we were gettings things ready for that platform. It's a convention but it helps when writing helper scripts.

We can clone and work on any subset of the entire tree by cloning just the repos we are interested in. Setting $LD_LIBRARY_PATH and $PATH helps when testing builds in their sandboxes. You still need to get the compiler/linker to construct paths into the sandboxes instead of the standard release area.

This is what the pkg-config command does. It respects the $PKG_CONFIG_PATH environment variable which can be used to point to staged installs so that you don't have to deploy the package before building against it. The idea is so simple that you could write an equivalent command in an afternoon and extend it to work however you need in the event that pkg-config does not fit.

There's only two components that are needed to make this work:

1. a simple shell wrapper to aid in setting the env. variables
   on the fly.  Let's call it "devo".  That way you can say
   "devo foo bar baz" and it'll put
   foo/linux-x64/lib64/pkgconfig and bar/linux-x64/lib64/pkgconfig
   (assuming linux-x64 is the "make install"ed path)
   at the front of the PKG_CONFIG_PATH, foo/linux-x86/bin in PATH,
   etc.

   You can do without a wrapper by either setting the variables
   manually or by having a shell scriplet that you 'source'
   whenever you want the settings.

2. the build must use the pkg-config command when constructing
   include/library paths.

As I mentioned, perhaps you don't want to use pkg-config. The idea ("overridable projects using a single env. variable") is the important part. You can certainly write something tailored to your needs if you want something simpler.

-- 
		David