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-02-10 10:11:55 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!wn11feed!worldnet.att.net!207.35.177.252!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor References: <400A9B48.3060100@noplace.com> <400BD4B5.6000307@noplace.com> <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <401118FD.701@noplace.com> <40126B5E.8050205@noplace.com> <99wTb.4905$bp1.159188@news20.bellglobal.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Tue, 10 Feb 2004 12:57:30 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1076435796 198.96.223.163 (Tue, 10 Feb 2004 12:56:36 EST) NNTP-Posting-Date: Tue, 10 Feb 2004 12:56:36 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:5404 Date: 2004-02-10T12:57:30-05:00 List-Id: Jacob Sparre Andersen wrote: > Warren W. Gay VE3WWG wrote: ... > But don't you agree that allowing a preprocessor to work on package > specifications isn't exactly good Ada style. No argument. But I do have a problem to solve. The problem is ugly, and the solution might be ugly too ;-) > Then you can't trust the > package specifications anymore. Although I prefer a simple "choose an > appropriate package body" method, I can see some benefits of allowing > full preprocessing of package bodies. You might be using a different meaning for "trust" than I use. As I see it, it need not be any different trust-wise than #included source code in a C program. You know in advance that certain elements will be compiled certain way in certain environments. I can trust that to be the case no matter how many times that is called upon. I can also trust that things will be compiled in the other environments that will use them. I see no real issue here. I'll agree however, that it is bad style and ugly. > My main problem right now is: Is it possible to specify a sensible > common method for asking the compiler questions about the target > environment? How? That is the problem for Ada that has remained unsolved for (IMO) too long. > My first thought was to tell the user (of the compiler) to give the > compiler some appropriate flags, indicating the information needed for > selecting which package bodies to choose. But that would still leave > the problem of making those configuration decisions to the user > instead of automating them. The problem that exists now is not generating the configuration. That can be done a multitude of ways, and is done in Open Sourced projects all over the place. The problem is taking it from configuration to source code. That is where the rubber hits the road right now. C/C++ deal with this just fine. Ada is challenged here. > Could we ask the compilers to be able to tell us if some library (a > string indicating a library name) exists in a specific version (a > string indicating a version)? What do compiler vendors say to that? > > What other kinds of compile time switches do we want to be able to > make? Either based on user choice or on the configuration of the > target system. It is not up to the compiler to know what configuration to use. But given directions about the configuration, the job is to generate a compiled version of that solution ;-) >>I think because of the targeted end user, Open Sourced projects have >>a special "need", compared to perhaps the "typical" Ada project >>(whatever that is ;-) > > Yes. But users of Open Source software already seem to have agreed to > use Autoconf/Automake as their "standard" compile-time configuration > tool. How does that work on non-Unix systems BTW? Again, Autoconf et al work fine for C/C++ systems. It requires real gyrations to use it with Ada ;-) Presumably, Autoconf could be used in a CYGWIN environment, though I have not tried it myself. Windows is in some ways much easier to config for, since there are fewer variations than exist in the *NIX/*BSD world. There are of course, still variations, and one has to be concerned about what optional components are installed etc. The general approach to Windows seems to be to provide an Intel binary (setup) to do that work. >>The result of this discussion seems to suggest that most are >>resisting the idea, for different reasons. So be it. Maybe with >>time, resistance to the idea will fade as more people try to address >>the practical problems that Open Sourced projects face in Ada. One >>can hope ;-) > > I hope we can find a solution that makes it easier for people who > receive a source code package with an Ada program to just compile and > run the program, _without_ letting the whole C preprocessor hell loose > in Ada too. > > Greetings, > > Jacob The fact that a conditional compilation feature is made available, does not require it to be used. Just by mandating that it is not done by default should help. Certainly safety critical systems where perhaps this type of thing would not be tolerated, you can mandate that it never be used. So given the above, the real resistance is boils down to the argument "I don't want to ever see it". -- Warren W. Gay VE3WWG http://ve3wwg.tk