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 13:49:35 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!news2.telebyte.nl!news.jgaa.com!news.hacking.dk!pnx.dk!munin.nbi.dk!not-for-mail From: Jacob Sparre Andersen Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor Date: 10 Feb 2004 22:49:28 +0100 Organization: Munin Sender: sparre@sparre.crs4.it Message-ID: References: <400A9B48.3060100@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> NNTP-Posting-Host: 80.241.165.50 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: munin.grove.home 1076449772 25930 80.241.165.50 (10 Feb 2004 21:49:32 GMT) X-Complaints-To: sparre@munin.nbi.dk NNTP-Posting-Date: Tue, 10 Feb 2004 21:49:32 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:5408 Date: 2004-02-10T22:49:28+01:00 List-Id: Warren W. Gay VE3WWG wrote: > 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 ;-) :-( Do you have any examples, where you would have, or actually have, used a preprocessor on package specifications? (I hope I haven't missed some in the discussion) I probably make too simple systems, but I find it hard to imagine cases, where it wouldn't be more appropriate to - at least - keep the variant parts of the code away from package specifications. > > 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. My problem is that if the package specifications vary with the target environment, that means that all the code using that package also may have to vary with the target environment, and thus propagate use of conditional compilation. - I doubt that the ARG would let that into the standard. > > 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. Haven't anybody tried to put a suggestion together? > > 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. I am not sure I agree. > That can be done a multitude of ways, and is done in Open Sourced > projects all over the place. Yes, but the Open Source world has a de-facto standard for doing it. We should either get those tools to support Ada as well as they support C and C++ or make an easier and safer solution for Ada. > 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. I would say that that part is close to trivial - if we can agree to which granularity to support. At one extreme there is the current situation with no formalised conditional compilation, somewhere in between there is letting the compiler choose appropriate package bodies given the configuration parameters, and at the other extreme we have mandating something like the C preprocessor. Personally I would like to have the solution of letting the compiler choose appropriate package bodies. But without some level of automated detection of the target environment, it wouldn't be of much use, and I could just as well handle it myself as I do today. > 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 can understand your point of view, but if we really want to compete with `./configure && make && su -c make install`, we have to do better than that. If users have to find out which versions of which libraries are on their systems _and_ how to tell the compiler that information, we are already _far_ behind what I can do myself with existing tools and without much work. > Again, Autoconf et al work fine for C/C++ systems. It requires real > gyrations to use it with Ada ;-) Sure? I have never had to create an Autoconf/Automake configuration from scratch, but I find it hard to imagine that it requires excessive amounts of work to get it to do the testing needed to configure an Ada program. > The fact that a conditional compilation feature is made available, > does not require it to be used. Right. But programmers have an awful habit of using whatever tools available. > So given the above, the real resistance is boils down to the > argument "I don't want to ever see it". If you are talking about full C preprocessor style conditional compilation, you are certainly right. If we are talking about some intermediated solution, where the public part of package specifications are untouched by the conditional compilation mechanism _and_ we can include some implementation advise about the compiler guessing or asking the user the questions needed to resolve the conditional compilation, then I will most likely support it. Jacob -- "I don't want to gain immortality in my works. I want to gain it by not dying."