[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shared Libraries?

On 2 feb 2008, at 05.51, Mark Johnson wrote:
[...]

So why not abstract the cdb code out into a separate libcdb, with
provisions for linking statically or dynamically?  Let the user decide
which?  I think autoconf will do that with the proper dark
incantations (which can be clearly spelled out in  a README).  Sure,
it introduces new external dependencies to ucspi-tcp and djbdns, but
it would save them from carrying around duplicate cdb code.



I don't know djb's rationale for duplicating code among packages. I
do see some advantages though.

First of all, the package becomes completely self-contained. This is
not a bad thing in my opinion. From a user perspective, the package is
build and installed without much fuss. From a maintainer perspective,
all code in the package is 'owned' by that package which means that

  a) you can make any changes you want (or need) to it without
     worrying about (or actually) affecting other packages, and
  b) vice versa, you don't have to worry about changes made to
     other packages.

Taken together, point a and b means that once you've tested and made
sure that the whole package behaves as expected, nothing but changes
internal to the package will affect its behaviour (ok, not entirely
true, but you've at least _externalized_ eventual problems, so to speak).

Sure, the code might not change much, but if it needs to be changed,
the change can be made to one place instead of multiple.



True, and I'm personally in favor of eliminating duplicate code.
There is nothing however, that says djb isn't managing his code this
way behind the scene, and that what we see in official packages like
djbdns and ucspi-tcp are merely freezed revisions [1]. Also, in light
of my comment above, I can still see advantages in keeping different
"branches" of a library more or less detached from each other (when
the branches are mature enough one could merge them into a new major
revision of the library, and let the different projects re-branch off
from there).

On a side note (I really don't want to go too deeply into the unavoid-
able autoconf thread, but here I am doing it anyway), as a contrast
to autoconf and friends, I find the (hopefully redemptive) vaporware
redo [2] in conjunction with practices such as writing small test
programs that test dynamically for specific machine/os features [3]
an intriguing idea. (Yes, I admit it, I'm a djb code junkie :-).


Regards,
Malte

[1] I know, this doesn't help a project outside djb's control, which
    is what you're talking about.
[2] http://cr.yp.to/redo.html
[3] http://cr.yp.to/docs/unixport.html , second item in the list
    titled Notes to programmers.