Re: Naive question about system dependencies

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <85B716C4188@annwfn.com>, merlin@annwfn.com (Fred McCall) writes: 
|> In <35f559$mad@info.epfl.ch> weber@lglsun.epfl.ch Mats Weber writes: 
|>
|> >In many cases, a single package specification with different bodies
|> >solves the problem. In other cases, the private part of the package
|> >needs to be different in different variants (this means duplication of
|> >the spec in Ada 83, Ada 9X has significant imporvements for handling
|> >such cases).
|> >
|> >Using a good file naming convention helps a lot in managing the
|> >different versions. We use something like this: 
|> >
|> >sql_interface.ads                 (common package spec)
|> >sql_interface-oracle-vms.adb      (body for Oracle under VMS)
|> >sql_interface-sybase-unix.adb     (body for Sybase under UNIX)
|> >
|> >Despite the amount of code duplication, I prefer this to a preprocessor
|> >approach.
|>
|> One thing to be *very* wary of -- during maintenance, if you find and
|> fix a bug in one variant, you'd better check all those other alternate
|> bodies for the same bug and apply the same fix.  I agree with the
|> difficulty of reading heavily ifdef'd sources, but they do have the
|> advantage of putting all the source code in one place (which simplifies
|> source control on bug fixes).

Quite true.  That's why the design should strive to isolate the target
dependencies as much as possible.  Ideally, the multiple versions differ
only in a few very small units that define a few exported constants and
low-level subprograms differently, but invoke common code that
constitutes the bulk of the system.

--
Norman H. Cohen    ncohen@watson.ibm.com