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

From: Enrico Weigelt <weigelt@metux.de>
Date: Jan 30, 2011, 19:36 UTC
Message-ID: <20110130193603.GA327@nibiru.local>
In-Reply-To: <20110129232848.GC7676@gmail.com>

* David Aguilar <davvid@gmail.com> wrote:

Hi,

Show 5 quoted lines

> 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.

perhaps you'd like to have a look at my Briegel build tool:

    git://pubgit.metux.de/projects/briegel.git
    
;-)

> 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.

Did you have these branches for all packages ?

Show 6 quoted lines

> 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.

I'd suggest pushing everything through a sysroot'ed crosscompiler
and only install the absolute required dependencies in the sysroot
on each package build. This tends to show up a lot of programming
errors that otherwise stay unnoticed for a long time.
(Briegel goes exactly that way and handles it automatically ;-p)

> 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.

With sysroot, it's even a bit more cleaner, pkg-config can handle the path fixups automatically then.

> 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.

Actually, I only know of rare cases where pkg-config doesn't really fit. Mostly due bad software design. Once thing I'm yet missing is something pkg-config alike which replaces most of the autofool-tests (eg. whether the target supports some syscall, stack directions, etc).

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

Still there're lots of packages which dont use pkg-config. Some of those I'm already fixing in my OSS-QM project. (Everybody's invited to join in ;-))

cu

-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------