Len Budney writes:
> Apologies for this slightly off-topic post.
>
> Has Dan has revealed enough about his engineering methods for others
> to duplicate them? Does anybody want to, possibly producing sharable
> tools?
There are already existing tools out there that produce perfectly reusable
and recyclable code, which have been battleproven, and can easily handle
huge projects made out of modular parts. I have four projects, in which an
average of 50% of the code is shared amongst all four of them, and is
organized into about a dozen different subdirectories.
> The big open question for me is:
>
> 1. What does he use for source control, given that he builds in one
> directory, and bundles the same libraries with many packages? How
> is the repository organized? CVS etc. like hierarchies.
Initially RCS worked fine for me. In each directory of a shared module, I
simply set RCS to be a soft link pointing to a common directory.
However, lately due to increased complexity I upgraded to CVS, so that
changes to any shared code can be automatically propagated via one cvs
update, instead of having to remember to RCS co each individual file from
the shared RCS repository, for each project. Any time I switch projects I
just do a cvs update, and I'm all set.
And, because CVS is just a shell on top of RCS, moving to CVS was virtually
a no-op.
> 2. The ezmlm package contains files of form *=* which give a strong
> hint how his makefiles are generated [2].
That's nasically a simplified version of what autoconf and automake does.
They are standardized tools that everyone knows how to use. There's an
initial steep learning curve, but, after a while, it becomes as natural as
breathing.
> 3. Dan appears to track "functional units" of code, and appears to
> incorporate them into projects as units [5]. Perhaps using CVS
> modules or the like?
Easily handled via CVS, with autoconf and automake. Take a look at
sqwebmail - http://www.inter7.com/sqwebmail/, courier-imap -
http://www.inter7.com/courierimap/, and maildrop -
http://www.flounder.net/~mrsam/maildrop/. All three tools reuse about a
dozen functional modules, which are stored only once, in a single
repository. At any given time, actually, there might be very minor
differences in the same module within each individual package simply due to
the fact I don't package them as a tarball simultaneously, but only when
there's a functional upgrade.
But, ignoring those minor differences, although the base source code within
all three projects is identical, in some cases the autoconf/automake
scripts end up configuring the same module quite differently. For
example, look at the authlib library. Because Courier-IMAP includes the
libhmac module, authlib detects it and compiles some code that implements
CRAM-MD5 authentication, which uses the code from libhmac. The same
authlib module does not compile the CRAM-MD5 code when it is packaged as
part of sqwebmail, because sqwebmail does not include the libhmac library,
and it has no need for CRAM-MD5 authentication.
I just noticed that maildrop does not include the md5 module, because I
haven't worked on maildrop for a while, and haven't updated it. Therefore,
the userdb virtual account module can only set crypted passwords for the
userdb virtual account database. Simply adding the md5 module to the
maildrop build will result in userdb reconfiguring itself to offer an
option of storing passwords encrypted with the MD5 hash function,
permitting longer passwords.
> 4. All sources go into one directory; Perhaps because recursion defeats
> make's dependency checks [3,4]? Perhaps because many tools don't like
> to build things in subdirectories? Perhaps because his packages
> are pretty small, so it just doesn't matter?
It's quite convenient to package standalone modules as individual
subdirectory that can be plonked into any project, and have a top-level
configure script configure it. autoconf and automake have the necessary
resources to build a module hierarchy, so there's no need to badger djb for
this tools, since equivalent capabilities have been available in autoconf
and automake for years...
--
Sam
