Re: Standard Ada Preprocessor

["Warren W. Gay VE3WWG" <warren@ve3wwg.tk>]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> Matrix 10 POSIX environments x 10 versions of the same, x 4
>> different versions of a curses library. That leaves you with
>> 400 different custom (possibly groups of) packages to work
>> with. Real slick indeed. :(
> 
> One standard POSIX-Ada binding 

Impossible. Some UNIces provide some API structure members,
while others don't, or provide something else again. Yes,
you can dumb it down to a "standard" (or omit non-universal
functionality), but by doing so you throw away functionality.
I find that unacceptable.

> and one application-specific screen 
> control package leaves me with 4 different package bodies to deal with, 
> each of which contains code specific to one curses library. 

Ah, but you cannot assume that the binding for PDcurses,
is going to be the same for all different POSIX platforms!
Going from POSIX, to X Windows, to Win32, will change the
interfaces again. It is not this simple, as the level of
support changes depending upon the platform, and version
of the same (in some cases). Try it in an open sourced
project (as I have), and you'll be a little wiser for it.

> If you want to handle those package bodies as one big file that you 
> preprocess to get the desired version for a platform, go ahead. The 
> payoff was in creating the application-specific package.
> 
> The point should always be "what does the application require?", not 
> "what does the platform/environment provide?" 

When you code "bindings" you have to consider both. Sometimes
you can push the application requirments into the thick
binding, developing some distance from the thin one. But at
some level, you will _still_ have to look at OS and C library
level "requirements". Develop some Open Sourced code in
without gnatprep, and we'll see how portable it is ;-)

> Once you've done that you 
> can always hide the differences behind an application-specific interface.

There is hiding to be sure. But down at the C and OS level,
things get rather ugly when trying to be "portable". The
fault of this is not so much Ada, but trying to interface
to a predominantly non-Ada world.

>> Think "conditional compilation". I see the "how" as an
>> implementation detail, that need _not_ track the C/C++
>> experience.
> 
> This thread is about a standard preprocessor (see the subject). But as 
> someone who has done this kind of thing without a preprocessor and 
> prefer the results, I'm convinced that what's needed is a portable way 
> to tell the compiler to use the package body from the Win32 directory, 
> or from the UNIX directory, or from the VMS directory.

That functionality would help. But there is still a need for
more than that.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk