Code duplication and component-based distributions (was: Problem in debugging GPS)

["Ludovic Brenta" <ludovic@ludovic-brenta.org>]

Simon Wright wrote:
> Ludovic Brenta <ludovic@ludovic-brenta.org> writes:
>
> > Thus, I completely avoid the code duplication that AdaCore seem so
> > fond of.
>
> Just for interest -- do you mean object code duplication (ie, place
> the package's source code on the compiler's search path and recompile
> it for each project)?

No, I meant that I avoid both source and object code duplication. I
myself benefit by not having to recompile e.g. GtkAda when I compile
GPS. That alone shaves one hour off of a full build on my laptop
(thanks to my lean-and-mean build scripts, I hardly ever need a full
rebuild anyway).

Since the -dev packages for libraries provide the source files, I've
removed the duplicated sources from all of my .orig.tar.gz files. For
example, I've removed the templates_parser sources from AWS and GPS,
and I've removed the bundled parts of GNAT from ASIS and GPS.

As for the object code, the read-only ALI files in the -dev package
ensure that any package that build-depends on the -dev package will not
rebuild the library from source. Then, the run-time library package
provides a shared library; all packages that depend on that object code
just link with the shared library. For example, both gnat-gps and
libaws.so.2.2 link with libtemplates_parser.so.10, and libasis.so.2005
and gnat-gps link against libgnatvsn.so.4.1.

I took that approach to such extremes that I even created new libraries
that AdaCore thought impossible, or at least very difficult, to make;
namely libgnatvsn and libgnatprj. The GNAT tools (gnatmake and friends)
and ASIS have been using these libraries for a year now without any
problems, thank you very much. And the size of the GNAT tools went down
by 90%.

Similarly, since the duplicated templates_parsers in AWS and GPS were
different and incompatible at the source level, I created a separate
package that is compatible with both, by doing a checkout from CVS and
then patching further. That package is now in Etch, by the way.

All of that is dangerous; don't do it at home if you want a stable
system :) the danger is that I may break programs. Right now I'm stuck
on GPS because it crashes. I'm starting to get worried by the looming
freeze in Etch, and the transition to GCC 4.1 is not yet finished. I
think I've been too reliant on the "if it compiles, it will probably
work" attitude. This does not hold with GPS, unfortunately, since it
compiles but does not work.

> As a provider of components who doesn't care what OS the users have to
> cope with I find this a very natural way to deal!

In theory, yes, but this means you've got to be very good at
configuration management (i.e. the use-relationships between the
components), and at package management (i.e. installing and upgrading
all packages on the platform in a way that is consistent with the
desired configuration).

On OSs that do not provide good package management, like the one from
the Redmond, you're in for trouble. I think that that's why AdaCore
prefer code duplication to proper configuration and package management.
In those that do provide good package management, you've got to think
in terms of the whole system, and how each single component fits in.
That also requires good advance planning, and may require lock-step
development (i.e. while developing program P, you must wait for library
L to be formally released before you can use the new features in it;
that precludes truly parallel development of P and L).

So, good configuration management and good package management require
dedicated work and manpower.

I think it is interesting to contrast Gentoo or FreeBSD with Debian.
Gentoo and FreeBSD avoid binary compatibility issues by only
distributing source packages, and doing automatic builds as part of the
installation process. Debian takes the opposite and difficult route: it
provides prebuilt binary packages, and so the maintainers have to take
binary compatibility into account.

Also, Gentoo seems to favour completeness over consistency; they
provide several versions of GNAT (both GPL Edition and from the FSF)
and let the user decide which one they would prefer. They don't seem to
have a very strong policy as regards configuration management; they let
their users do that for themselves, with help from the package manager.
The GNU Ada Project seems to take the same route. In Debian, again I
take the opposite and difficult route favouring consistency over
completeness: I provide only one version of GNAT (namely GCC 4.1) but
make sure everything works together.

-- 
Ludovic Brenta.