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-22 07:03:17 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!nntp.theplanet.net!inewsm1.nntp.theplanet.net!easynet-monga!easynet.net!feed.news.tiscali.de!eusc.inter.net!cs.tu-berlin.de!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor Date: Thu, 22 Jan 2004 15:03:17 +0000 (UTC) Organization: GMUGHDU Message-ID: References: <400BD4B5.6000307@noplace.com> <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <400FD4F7.8050805@noplace.com> NNTP-Posting-Host: l1-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1074783797 21433 134.91.1.34 (22 Jan 2004 15:03:17 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Thu, 22 Jan 2004 15:03:17 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/800)) Xref: archiver1.google.com comp.lang.ada:4650 Date: 2004-01-22T15:03:17+00:00 List-Id: Marin David Condic wrote: : Better than Gnat, but still not terribly useful if you want to make code : that will compile on both a Gnat and an Aonix platform. 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. -- Georg