From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38159b1b5557a2e7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-30 05:09:21 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!elnk-pas-nf1!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread1.news.atl.earthlink.net.POSTED!d9c68f36!not-for-mail Message-ID: <401A577B.3000904@noplace.com> From: Marin David Condic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (OEM-HPQ-PRS1C03) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor References: <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <400FC8E8.2040100@noplace.com> <4011127C.4030801@noplace.com> <101377e54car5cc@corp.supernews.com> <4017AAEF.1020304@noplace.com> <4018FF55.8030800@noplace.com> <101j4si8uc4taa0@corp.supernews.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 30 Jan 2004 13:09:20 GMT NNTP-Posting-Host: 209.165.2.58 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.news.atl.earthlink.net 1075468160 209.165.2.58 (Fri, 30 Jan 2004 05:09:20 PST) NNTP-Posting-Date: Fri, 30 Jan 2004 05:09:20 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:5091 Date: 2004-01-30T13:09:20+00:00 List-Id: 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 ======================================================================