Re: Standard Ada Preprocessor

[Marin David Condic <nobody@noplace.com>]

That's a fair point. No matter what you do, you'll have to have some 
kind of "outside the language" mechanism for specifying which path you 
want to go down and that isn't under the control of the language.

But do consider this: Something like "gnatmake" has pretty much 
eliminated for me needing to worry about build scripts in most 
situations. The *language* goes out and figures out what is out of date 
and what needs to be included in the build. So long as I can point to a 
single pile of files and say "there's a build in there somewhere - you 
go figure it out...", Ada does a marvelous job with it. Compared to C, 
this is a major improvement in many respects.

So it might not be that much of a stretch to ask something like gnatmake 
to go decide which way to branch in selecting files from two or more 
alternate paths within that pile of files. Something as simple as saying 
'gnatmake -buildstring="Go Down Path A"' might be sufficient so long as 
there was some way of picking up the "Path A" variants of files via some 
language mechanism so that I knew I could take the same pile of files 
and hand them off to Janus Ada or Aonix or any other compliant compiler 
and know that someone with little familiarity with my pile of code could 
use minimal instructions and direct an appropriate build for his platform.

It all goes to enhancing Ada's ability to be "The Portability Language". 
It already does so much in that respect that I think its a shame it 
can't seem to find a way to get around the fact that no two compilers or 
environments are ever going to be identical. "Outside The Language" 
solutions exist - but then we're no better than C (or other languages) 
in that regard. In some ways worse since at least C provides a (maybe at 
times ugly) way of directing the compiler down alternate paths.

MDC

Randy Brukardt wrote:
> 
> Right. There is no such thing as a compile-time solution that doesn't change
> some code or management artifact like build scripts. If you're using
> conditional compilation, you have to set the choice of which to use
> somewhere. You're going to have to manage that code or scripts with some
> form of configuration management per configuration. You cannot avoid this
> part of the problem on anything but the tiniest one-person projects (where
> you might actually be able to remember a bucket of special command-line
> switches - but as I get older, I find I can't even do that anymore...). So,
> given that you have a solution to the managment of separate code/build
> scripts, why would you not apply it to managing separate specs and bodies?
> And clearly, separate implementation-dependent code is always preferable
> (and don't forget that subunits also can be used to keep
> implementation-dependent stuff separate).
> 
> There are cases where Ada's existing conditional compilation doesn't work
> (or makes the code much harder to read), but they're rare enough that going
> further is a very tough sell.
> 
>                           Randy.
> 
> 
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================