Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)

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

Robert I. Eachus wrote:
> 
> But again you are trying hard to make things difficult for yourself. 
> First, if the interface to Gnat_Solution and Aonix_Solution are 
> identical, why do you want to make source that uses the interface 
> compiler dependent?  Both the Gnat and Aonix packages should be named 
> Solution. ;-)
> 
They may not be "identical" in all respects - remember rep clauses! I 
can have declarations that *won't* compile on some compiler. However the 
type, object, subprogram, etc. *names* might be identical.

And I'd like a way to make sure I never try to compile/link/run a Gnat 
package body with an Aonix compiler/linker. Maybe I can start with an 
identical spec and two different bodies (maybe!) and how is it I make 
sure the right body gets picked up by the right compiler? That's an 
environmental thing - so I have to figure that one out and come up with 
some scheme for handling that. (makefiles, CVS trees, whatever. It won't 
be portable.)

All you can do is delay the problem with indirection - you can't make it 
go away. Sooner or later, you've got code that compiles for one 
environment and not for another. Now manage it. (Or maybe I could have a 
conditional compile preprocessor and have just *one* set of files to 
deal with? :-)

> Now that you have gone that far, you have banished all of the compiler 
> dependencies to the body of Solution.  Either use the tricks I 
> described, or if the bodies are so different that it makes sense to 
> mantain them separately, provide them as separate files, and use 
> different makefiles for Aonix and Gnat.  (Gnat likes to dictate the 
> names of files, but it does provide facilities for overriding that.)
> 
> 
Yup. I've been saying all along that I *know* I can solve the problem 
with some kind of build process and/or CM. Separate makefiles (if you 
have makefiles) or some other OS/third-party-product dependent answer is 
out there. We've been building different builds of the same thing for a 
long time now and a solution does exist. I have *never* said you 
couldn't find a way to do it with technology that exists today. A 
solution does exist.

Just not a *Portable* solution and one you can count on being there all 
the time. And not always a *simple* solution to a sometimes *simple* 
problem. You're dependent on some kind of 
outside-the-language-can't-count-on-having-it-there patch to deal with 
the fact that compilers and OS's and libraries and targets and 
environments are *not* always identical.

Also, its sometimes "Overkill" to suddenly have to buy into separate 
builds with separate sources and separate CM on them, etc. If you need 
just a small handful of things fixed at some low level, you may not want 
to force your project to forever be doing that extra maintenance effort 
and bookeeping that goes along with handling divergent copies of source 
code.

I'm not saying I can't find a way to live without it. I'm just saying it 
would help simplify a lot of problems if we had something like 
conditional compilation or some other patch to deal with differences 
between environments. I'd like to have a way of *not* having divergent 
copies of source code - or if they must diverge, then give me a 
mechanism for auto-selecting them that I can count on having in any 
place I take the code.

MDC

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

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