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-24 08:06:42 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!logbridge.uoregon.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread3.news.atl.earthlink.net.POSTED!d9c68f36!not-for-mail Message-ID: <401297E9.6020809@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 (Was: why ada is so unpopular ?) References: <49cbf610.0401170627.79c3dfe5@posting.google.com> <400A9B48.3060100@noplace.com> <400BD4B5.6000307@noplace.com> <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <400FC8E8.2040100@noplace.com> <_JSdna166JuxFo3dRVn-hg@comcast.com> <401115B7.5020205@noplace.com> <401268B4.1010704@noplace.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 24 Jan 2004 16:06:04 GMT NNTP-Posting-Host: 209.165.25.157 X-Complaints-To: abuse@earthlink.net X-Trace: newsread3.news.atl.earthlink.net 1074960364 209.165.25.157 (Sat, 24 Jan 2004 08:06:04 PST) NNTP-Posting-Date: Sat, 24 Jan 2004 08:06:04 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:4778 Date: 2004-01-24T16:06:04+00:00 List-Id: 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 ======================================================================