From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6068b2e70032965b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!m7g2000cwm.googlegroups.com!not-for-mail From: "Ludovic Brenta" Newsgroups: comp.lang.ada Subject: Code duplication and component-based distributions (was: Problem in debugging GPS) Date: 28 Sep 2006 03:53:49 -0700 Organization: http://groups.google.com Message-ID: <1159440829.816174.177920@m7g2000cwm.googlegroups.com> References: <22c29$4518d54e$50632e62$3203@news.chello.hu> <451a7624$1@news.post.ch> <87d59hz4rp.fsf@ludovic-brenta.org> NNTP-Posting-Host: 212.190.145.10 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1159440835 12254 127.0.0.1 (28 Sep 2006 10:53:55 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 28 Sep 2006 10:53:55 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7,gzip(gfe),gzip(gfe) X-HTTP-Via: 1.1 SEVPXS01 Complaints-To: groups-abuse@google.com Injection-Info: m7g2000cwm.googlegroups.com; posting-host=212.190.145.10; posting-account=ZjNXewwAAADyBPkwI57_UcX8yKfXWOss Xref: g2news2.google.com comp.lang.ada:6796 Date: 2006-09-28T03:53:49-07:00 List-Id: Simon Wright wrote: > Ludovic Brenta 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.