Re: Standard Ada Preprocessor

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

Jacob Sparre Andersen wrote:

> Warren W. Gay VE3WWG wrote:
...
> But don't you agree that allowing a preprocessor to work on package
> specifications isn't exactly good Ada style.  

No argument. But I do have a problem to solve. The problem
is ugly, and the solution might be ugly too ;-)

> Then you can't trust the
> package specifications anymore.  Although I prefer a simple "choose an
> appropriate package body" method, I can see some benefits of allowing
> full preprocessing of package bodies.

You might be using a different meaning for "trust"
than I use. As I see it, it need not be any different
trust-wise than #included source code in a C program.
You know in advance that certain elements will be compiled
certain way in certain environments. I can trust that to
be the case no matter how many times that is called upon.

I can also trust that things will be compiled in the
other environments that will use them. I see no real
issue here. I'll agree however, that it is bad style
and ugly.

> My main problem right now is: Is it possible to specify a sensible
> common method for asking the compiler questions about the target
> environment?  How?

That is the problem for Ada that has remained unsolved
for (IMO) too long.

> My first thought was to tell the user (of the compiler) to give the
> compiler some appropriate flags, indicating the information needed for
> selecting which package bodies to choose.  But that would still leave
> the problem of making those configuration decisions to the user
> instead of automating them.

The problem that exists now is not generating the configuration.
That can be done a multitude of ways, and is done in Open
Sourced projects all over the place. The problem is taking
it from configuration to source code. That is where the
rubber hits the road right now. C/C++ deal with this just
fine. Ada is challenged here.

> Could we ask the compilers to be able to tell us if some library (a
> string indicating a library name) exists in a specific version (a
> string indicating a version)?  What do compiler vendors say to that?
> 
> What other kinds of compile time switches do we want to be able to
> make?  Either based on user choice or on the configuration of the
> target system.

It is not up to the compiler to know what configuration to
use. But given directions about the configuration, the job
is to generate a compiled version of that solution ;-)

>>I think because of the targeted end user, Open Sourced projects have
>>a special "need", compared to perhaps the "typical" Ada project
>>(whatever that is ;-)
> 
> Yes.  But users of Open Source software already seem to have agreed to
> use Autoconf/Automake as their "standard" compile-time configuration
> tool.  How does that work on non-Unix systems BTW?

Again, Autoconf et al work fine for C/C++ systems. It requires
real gyrations to use it with Ada ;-)

Presumably, Autoconf could be used in a CYGWIN environment,
though I have not tried it myself. Windows is in some ways
much easier to config for, since there are fewer variations
than exist in the *NIX/*BSD world. There are of course, still
variations, and one has to be concerned about what optional
components are installed etc. The general approach to Windows
seems to be to provide an Intel binary (setup) to do that work.

>>The result of this discussion seems to suggest that most are
>>resisting the idea, for different reasons. So be it. Maybe with
>>time, resistance to the idea will fade as more people try to address
>>the practical problems that Open Sourced projects face in Ada. One
>>can hope ;-)
> 
> I hope we can find a solution that makes it easier for people who
> receive a source code package with an Ada program to just compile and
> run the program, _without_ letting the whole C preprocessor hell loose
> in Ada too.
> 
> Greetings,
> 
> Jacob

The fact that a conditional compilation feature is made available,
does not require it to be used. Just by mandating that it is
not done by default should help. Certainly safety critical
systems where perhaps this type of thing would not be tolerated,
you can mandate that it never be used.

So given the above, the real resistance is boils down to the
argument "I don't want to ever see it".
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk