On Sat, Jan 29, 2011 at 08:42:59PM +0100, Enrico Weigelt wrote:
> * Jakub Narebski <jnareb@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html