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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d54630460ea6a38e X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: system dependencies Date: 1997/05/31 Message-ID: <01bc6d67$69a96720$LocalHost@xhv46.dial.pipex.com>#1/1 X-Deja-AN: 245096947 References: Organization: UUNet UK server (post doesn't reflect views of UUNet UK) Newsgroups: comp.lang.ada Date: 1997-05-31T00:00:00+00:00 List-Id: Ken Raeburn wrote in article ... [...] > 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.