* David Aguilar <davvid@xxxxxxxxx> wrote:
Hi,
> 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 ?
> 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@xxxxxxxx
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
--
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