Re: Standard Ada Preprocessor

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

Ole-Hjalmar Kristensen wrote:

>>>>>>"JC" == Jeffrey Carter <spam@spam.com> writes:
>     JC> Warren W. Gay VE3WWG wrote:
>     >> Jeffrey Carter wrote:
>     >>> 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.
>     JC> There is a standard POSIX-Ada binding (Florist is an implementation of
>     JC> this standard)  to the  POSIX standard. If  you want something  not in
>     JC> this standard, obviously  you're going to have to  provide it yourself
>     JC> on some platforms.  If you're on a platform  that doesn't provide some
>     JC> of the  functionality, then it's not  a POSIX system.  In neither case
>     JC> are you dealing with different versions of POSIX.
> 
> Which does not matter if what you are doing is maintaining a program
> which is running on multiple platforms and is compiled with multiple
> compilers. The program has to run even if the platform does not
> support a standard package like Florist. How many platforms is Florist
> really available on, btw.? 

Listen, C programmers do this thing every day. "If some feature
is available, then do it this way, else do 'it' in a more
inferior way".

Just because you write to "any platform", doesn't mean you
have to dumb down the code for all platforms. If one O/S gives
me an efficient way to do something, and I care to take
advantage of this, then I can do just that with conditional
compilation.

By saying that an Ada program would never do that, has again
condemned it to be inferior in some cases (which, IMO,
is an entirely unnecessary limitation).

> What matters is how do I do this while keeping the code readable and
> maintainable.

Of course! I could argue that conditional compilation may
make it clearer where I'd run into portability problems
on some platforms, because the different offending code
is right in front of me (vs sitting somewhere else,
unexplored).

> One way to combat the combinatorial explosion of platforms * compiler
> * library is to explicitly test for the features of the environment
> you really need to know, not assume something because of a particular
> platform/compiler. This is the approach typically used by projects
> using the 'configure' tool.

Yes, and that ./configure tool generates files that drive
a conditional compile process. But no amount of Ada if
statements can help you with conditionally with-ing certain
packages, and conditional code that have to distinguish
between the code that must work around differences and
limitations, and deal with optional members of records etc.

But this horse has been beaten to death already in this
thread, and I see no reason to expand upon it again.

> I would really like to have some standard configuration tool which
> could take such parameters as input and produce a version of the
> system tailored to the environment in which it is to be compiled and
> run. 

This is just a high level statement of what has already
been discussed. So how are you going to _implement_ this?

   1. Preprocessing?
   2. Conditional compilation?
   3. Generate source code?

The problem with #3 (which is what you seem to be suggesting)
is that when there is a compile time problem, or a maintenance
issue, you end up wanting to work with the generated files. BUT,
you know you have to remember to work with the original INPUT
files, that were used to generate it. #3 actually describes
the gnatprep case, and there are options to make it easier
to work this way (eg. an option that relates the line #
back to the one in the original input file). But every once
in a while, I end up modifying the wrong file by accident.
I hate this. Conditional compilation would be a better
solution for the developer because it is less error prone,
and it is more natural.

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