Re: Standard Ada Preprocessor

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

I agree that if you can isolate something down in a low-level "System 
Dependency" package and swap those out easily, that you have *an* answer 
to some (if not all) problems. I've done this thousands of times. I've 
described cases elsewhere in this thread that *must* be dealt with at 
compile time (either by having separate configuration dependent units 
and some kind of conditional build tools or by having conditional 
compilation.) I'll bet you've even encountered things like a given 
declaration that works fine on one compiler but doesn't work on another 
or a statement that is legal and compiles for one compiler but is 
illegal for another. There are all sorts of allowed compiler differences 
- without even bringing up the subject of trying to get around compiler 
bugs.

So if there's issues that have to be resolved at compile time and I 
can't guarantee that there is some external configuration management 
and/or build tools available to make maintaining separate units possible 
(if not always desirable) then I want some kind of conditional 
compilation to help me maintain a single body of code that works for 
more than one configuration.

MDC


Georg Bauhaus wrote:
> What kind of difficulties do you see that could be better solved
> by a preprocessor? (Things supported in GNAT but not ObjectAda or vice
> versa? Dependence on pragmata?)
> 
> I have code that is compiled by OA 722, by GCC 34, but not by GNAT 3.15p.
> Ada source text is chopped where necessary using make.
> (Operating) System specific routines are are assembled into a
> package hierarchy (which I naively had top-level-named "System" (and
> that triggers a bug box in GCC 34 after looping (the maintainers
> say that, obviously, a library unit should not be modified...)))
> Then a branch renames package Systems.Windows, another renames
> package Systems.UNIX (or similarly).
> 
> The problem that leads GNAT 3.15p to reject another unit is
> apparently a bug in GNAT 3.15p that has been fixed in GCC 34.
> I like this better than having to construct sources around a
> compiler bug/limitation using hopefully temporary preprocessor #ifs.
> 



-- 
======================================================================
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

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