What is the best approach to share code between repositories?

[Mike Meyer]

On Mon, 28 Jun 2010 15:09:43 +0200
Didly <didlybom at gmail.com> wrote:

> On Thu, Jun 24, 2010 at 1:24 PM, Mike Meyer <mwm at mired.org> wrote:
> 
> > On Thu, 24 Jun 2010 12:03:20 +0200
> > Didly Bom <didlybom at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I'd like to get your advice on how to share some code between different
> > > repositories.
> >
> > I think you're taking the wrong approach by thinking of this as "code
> > sharing" instead of "package sharing" (where packages are what you get
> > from building code).
> >
> > > We have a two C modules that share some code. In particular we have a
> > driver
> > > and a library that uses that driver. To build the library you need to use
> > > several header files from the driver as well as the compiled driver
> > package
> > > (a ".so" file). The driver header files that are needed by the library
> > are
> > > contained in several different folders in the driver repository, while
> > the
> > > library project expects them to be all in the same "include" folder.
> > >
> > > We publish the library to other teams in our company. For many reasons
> > these
> > > other teams do not need to have (and are not interested in having) access
> > to
> > > the actual source code of the driver. However, they need to have access
> > to
> > > the library source code.
> >
> > Don't they need the driver binary as well - at least at some point? If
> > so, how do they get that? I would expect that to be made available by
> > the build system, delivering a tarball (or zip, or whatever)
> > containing the finished application along with the driver build that
> > it expects to run against for installation and testing.
> >
> 
> Mike, sorry for the late replay to your informative post. I've just had no
> time to go through it in detail until today.
> 
> In our setup the library developers don't really need the driver binary,
> since they are not linked. Instead the library talks to the driver via
> message passing (the library runs on user space while the driver runs at the
> kernel level). However, the library contains some stub objects that have the
> same interface as the driver (hence the need for the driver header files).

That's not that much different from what we do - at least in some of
the cases. However, in order to test the finished product, the
binaries that the application code talks to (in this case, your
driver) has to be installed. Can your developers test without the
driver?

> If the driver header files change, the library stubs may need to be changed
> according to the driver header changes, but we'd like to be able to get the
> header changes from the drive repository by pulling from it (although it
> seems this is just not possible).
> 
> We dealt with the issue of builds needing headers by making them
> > another build package from that source repository. Granted, they
> > didn't go into the final product, but they were available - selected
> > by the source version that was used to "build" them - in the build
> > area for anything that listed those headers as a requirement.
> >
> > Developers didn't need to check out the header sources. The build
> > system would install the appropriate "header package" if it was
> > available; if not it would check the repo out and build the package
> > from sources on a build machine. Probably build the driver at the same
> > time, since that was most likely both required by the build and not
> > yet built as well. If the developers needed to edit or read those
> > headers for some reason, they could clone that repo just like any
> > other part of the project, assuming they had permission to do so.
> >
> > I think this would solve most of the issues you listed. On the other
> > hand, it may be overkill for something that's just an
> > application+driver (we were building embedded Linux distros), in which
> > case maybe this'll point you in the right direction.
> >
> 
> So, if I understand you properly, your proposal is to use the build system
> to fetch the latest version of the header sources (and binaries, if needed)
> and then do the actual build of the library? This means that the header
> files would not be part of the library repository at all, right?

Yup. header files are a "binary package" that is built using the
driver sources (which includes the headers). The header files aren't
part of the library repository at all. If a developer needs to *edit*
them - as opposed to build against them - they have to use the driver
repository, complete with it's authentication, just like if they
wanted to tweak the driver proper. To build against them, you install
the header package, just like you'd install the driver package if you
neeed to run it.

Having the build system do all this makes sure the issues of install
location, etc. all get done right.

      <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org