Re: system dependencies

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

Ken Raeburn <raeburn@cygnus.com> wrote in article
<tx1bu5ttzs3.fsf@cygnus.com>...
[...]
> Oh and a general question: How do you usually deal with OS or
> configuration dependencies in Ada?  For example, some systems have the
> utmpx functions, some don't; some have wait4, some don't.  Maybe I'm
> building a package with a backwards-compatibility option enabled; maybe
> it's disabled.  In C and UNIX, I'd use #ifdef and maybe an
> autoconf-generated script to test the system characteristics and
> user-provided options, and define some macros for conditional
> compilation.
> 
> The conditionally-compiled region can be very small.  Of course, there
> are times when it's large, and when it seems worthwhile to use a separate
> source file.  But there are times when it isn't and it doesn't....


As a first resort, what you should do is to write your Ada program so that
it detects which environment it is running in (or has been compiled in),
and automatically adapts itself accordingly. So, if it may run under
environment A with useful procedure P1, or under environments B and C with
inferior procedure P2, you should write code like this:

if Environment_Group = A then
   P1;
else
   -- do things by hand here not done by P2
   P2;
end if;

This approach has the advantage of requiring only one version of your
source code, and the (immense) advantage that the software automatically
configures itself, in effect, thus avoiding accidents.

In those (unlikely) circumstances when, for reasons of reducing executable
size or increasing its speed, it is not acceptable to have 'shiralee' code,
put the different versions in separate files, and use configuration
management (or just file renaming!) to engage the right version when
compiling for each target. When you have to do this, it is vital that you
carefully document the different versions, and double-check to make sure
this documentation is comprehensive and accurate.

In all circumstances, it is important that you place all system-dependent
code in 'wrappers'. So, for example, if you have a procedure provided by
environment A which draws a line on the screen, but no such facility in
environments B and C (only pixel setting, say), you should write a wrapper
procedure to draw a line as follows:

procedure Draw_Line(P1, P2: in Point_Type) is
begin
   if Environment_Group = A then
      Fancy_GUI.Draw_Line(P1,P2);
   else
      -- routine which draws line using Set_Pixel(X,Y) procedure
   end if;
end;

You might then want to group all such wrapper stuff in a package, and this
package can then (if necessary) have different bodies (in separate files)
for different environments. I repeat, only do this if necessary. Observe
that, in this example, if Environment_Group and A are both static,
unnecessary code may be eliminated from the executable anyway.

Nick.