RE: Preprocessor question
Ok, I've finally given in and fixed this. From experience there are numerous strange subtelties with cpp, but I haven't found any killers yet. We *have* to use -traditional, otherwise '//' is interpreted as a C++ comment. Sigh. The command line I'm using in hscpp is now '$CPP -undef -traditional -
Re: Preprocessor question
On Tue, Jul 13, 1999 at 03:26:27 -0700, Simon Marlow wrote:
> > Use `gcc -E -` then.
>
> Good point :-)
nearly..., but we have to use '$CPP -x c-header' which would expand to
'gcc -E -x c-header', otherwise gcc wants to link those temporary *.lpp
files :-(
IMHO '-x c-header' just means to gcc:
"READ MY LIPS: THIS HAS TO BE PREPROCESSED, NOT LINKED"
But afters some more tests, I have to admit that it's worse: in mkdependHS,
$Cpp must be run *with* '-' in '&run_something("... | $Cpp...");'.
In hscpp OTOH, it has to be run *without* dash, because hscpp gets its input
from command line, and else waits forever on stdin...
Nevertheless, this is pretty much straight-forward to me: if there is input
from stdin, one has to use '-', otherwise not...
> We also like to get as clean a cpp as possible - if you go through gcc -E
> you get a whole bunch of symbols defined, and cpp gets passed the -lang-c
> flag (whatever that means, but it looks pretty scary).
also goes away with '-x c-header'
Cheers,
Michael
--
Fog Lamps, n. (see also ->"Idiot Lights"):
Excessively (often obnoxiously) bright lamps mounted on the
fronts of automobiles; used on dry, clear nights to indicate that the
driver's brain is in a fog. -- fortune cookie
Re: Preprocessor question
Michael Weber wrote: > [...] maybe the *BSD, OSF, and Windows folks should do the above > tests, too... This seems to work on Alphas, too: -- $ uname -srm OSF1 V3.2 alpha $ echo TEST | gcc -E -DTEST=works - # 1 "" works $ echo TEST | /lib/cpp -DTEST=works - # 1 "" works $ echo TEST | /usr/bin/cpp -DTEST=works - # 1 "" works $ echo TEST | /usr/ucb/cpp -DTEST=works - # 1 "" works -- $ uname -srm OSF1 V4.0 alpha $ echo TEST | gcc -E -DTEST=works - # 1 "" works $ echo TEST | /lib/cpp -DTEST=works - # 1 "" works $ echo TEST | /usr/bin/cpp -DTEST=works - # 1 "" works $ echo TEST | /usr/ucb/cpp -DTEST=works - # 1 "" works -- Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: Preprocessor question
On Tue, Jul 13, 1999 at 17:47:27 +0900, Manuel M. T. Chakravarty wrote: > Simon Marlow <[EMAIL PROTECTED]> wrote, > It isn't strictly speaking hardcoded, it's set up when you configure a binary distribution. So if you move gcc or install a new version, you need to re-install ghc. Yes, and that's a thing which should not happen: one installs a new package and mysteriously other packages begin to break... :-( Even worse: consider this being done by the admin or automatically, i.e. where problem resolution isn't simple... >>> I am sure that it is clear that a binary distribution with strict >>> dependencies on locations of other tools is far from ideal. That's exactly why I wrote the original message :-) > > This probably isn't the case for RPM's, but as you noted in your message > > it's up to the package builder to arrange for the location of cpp and other > > tools to be configured at install time. >>> [...] it would be nice if the path (and any other similar dependencies) >>> where located in a dedicated file where they are easy to find and patch. > > One possibility would be to have a `ghc-cpp' script, which is a one liner > and just `exec's cpp. We could either patch this script or have different > versions `ghc-cpp-', which are linked to `ghc-cpp'. What do you > think? *hmm* IMHO we already have one: 'hscpp'. As I said, ghc doesn't make use of $RAWCPP, and mkdependHS could use hscpp instead of calling cpp directly. Besides, SimonM mentioned that 'gcc -E' is a Bad Thing. I tried CPPs from gcc-2.7.2.3, gcc-2.8.1 and egcs-2.91.66, and they do accept input from stdin (note the dash): == $ echo TEST|gcc -E -DTEST=works - # 1 "" works == However, cpp does the same without the dash, but adding a dash _doesn't_ break things. == $ echo TEST|cpp -DTEST=works - # 1 "" works == Regarding unusual places where CPP lives on some systems, this should be (is already?) solved by autoconf. IIRC, ghc relies heavily on gcc's/egcs's features on all platforms, so we loose, if there is none, anyway. autoconf will always prefer an installed gcc over any other compiler, and thus also "gcc -E" over anything else. So the only things we have do, are: * in aclocal.m4, set $fptools_cv_gnu_cpp="$CPP -" and put this into hscpp's $RAWCPP * make mkdependHS use hscpp * remove $RAWCPP from perl scripts, that don't make use of it BTW: I tried Solaris and Linux platforms only, maybe the *BSD, OSF, and Windows folks should do the above tests, too... Cheers, Michael -- standard construction, def: "sort of a mathematical equivalent of 'hey you'" -- Phil Wadler, "Monads"
RE: Preprocessor question
Simon Marlow writes: > > We also like to get as clean a cpp as possible - if you go through gcc -E > you get a whole bunch of symbols defined, The -undef option gets rid of most of those. > and cpp gets passed the -lang-c flag (whatever that means, but it > looks pretty scary). The other possibilities are -lang-c++, -lang-objc, etc. It's to do with things like comment syntax and Objective C's #import directive. It's not as scary as it looks, I think :-) Tony. -- f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] Winner, International Obfuscated C Code Competition 1998
RE: Preprocessor question
> Simon Marlow <[EMAIL PROTECTED]> wrote: > > > > - mkdependHS and friends need a cpp that accepts input on > > stdin, and files that don't end in ".c". That rules out > > 'gcc -E'. > > Use `gcc -E -` then. Good point :-) We also like to get as clean a cpp as possible - if you go through gcc -E you get a whole bunch of symbols defined, and cpp gets passed the -lang-c flag (whatever that means, but it looks pretty scary). Cheers, Simon
Re: Preprocessor question
Simon Marlow <[EMAIL PROTECTED]> wrote: > > - mkdependHS and friends need a cpp that accepts input on > stdin, and files that don't end in ".c". That rules out > 'gcc -E'. Use `gcc -E -` then. Tony. -- f.a.n.finch [EMAIL PROTECTED] [EMAIL PROTECTED] Winner, International Obfuscated C Code Competition 1998
RE: Preprocessor question
Simon Marlow <[EMAIL PROTECTED]> wrote, > > > It isn't strictly speaking hardcoded, it's set up when you > > configure a > > > binary distribution. So if you move gcc or install a new > > version, you need > > > to re-install ghc. > > > > I understand the technical issues, but the problem is that > > installing/compiling GHC from source is a *pain* (and > > requires you to have a machine with a lot of memory and a > > fast CPU or a spare machine, which you can afford doing > > nothing else for quite a while). So, IMHO, binary > > distributions are *very important* for GHC. I am sure that > > it is clear that a binary distribution with strict > > dependencies on locations of other tools is far from ideal. > > I think you misunderstood - a standard GHC binary distribution is > independent of the location of cpp on the target machine. It is discovered > when you unpack the distribution and type './configure'. So, all that's > needed is to re-install the binary distribution. Sorry, I indeed misunderstood. (It is too long since I installed a GHC .tar.gz binary distribution.) > This probably isn't the case for RPM's, but as you noted in your message > it's up to the package builder to arrange for the location of cpp and other > tools to be configured at install time. Correct me, if I am wrong again, but if I remember correctly, GHC's .tar.gz binary distributions can be configured either in-situ in one subtree or be made to install into some other place. Unfortunately, both is unsuitable for an RPM (or, as far as I know, for a Debian package). It is a Bad Thing to move files in a RPM post-install script as one of the nice features of RPM is that it keeps track of all the install files and allows to remove complete packages with only a few keystrokes (or mouse clicks). On the other hand, it is necessary that the files stored in the RPM are distributed to /usr/bin, /usr/lib, /usr/doc etc if we want to follow the Linux installation guidelines - which we definitely want (so the standard in-situ installation won't do either). In other words, a Good RPM is snapshot of a selected set of files scattered over the /usr subtree. The post-install script should just patch some configuration file. Thus, > > [...] it would be nice if the path > > (and any other similar dependencies) where located in a > > dedicated file where they are easy to find and patch. One possibility would be to have a `ghc-cpp' script, which is a one liner and just `exec's cpp. We could either patch this script or have different versions `ghc-cpp-', which are linked to `ghc-cpp'. What do you think? Cheers, Manuel
RE: Preprocessor question
> > It isn't strictly speaking hardcoded, it's set up when you > configure a > > binary distribution. So if you move gcc or install a new > version, you need > > to re-install ghc. > > I understand the technical issues, but the problem is that > installing/compiling GHC from source is a *pain* (and > requires you to have a machine with a lot of memory and a > fast CPU or a spare machine, which you can afford doing > nothing else for quite a while). So, IMHO, binary > distributions are *very important* for GHC. I am sure that > it is clear that a binary distribution with strict > dependencies on locations of other tools is far from ideal. I think you misunderstood - a standard GHC binary distribution is independent of the location of cpp on the target machine. It is discovered when you unpack the distribution and type './configure'. So, all that's needed is to re-install the binary distribution. This probably isn't the case for RPM's, but as you noted in your message it's up to the package builder to arrange for the location of cpp and other tools to be configured at install time. > A (somewhat unsatisfactory) solution for package > manager-based distributions (like .rpm or .deb) would be to > use a post-install script that searches for cpp and patches > the path. To make this easier, it would be nice if the path > (and any other similar dependencies) where located in a > dedicated file where they are easy to find and patch. > > > I suppose we can put in a configure test for known locations of cpp > > (/lib/cpp, /usr/libexec/cpp, /usr/lib/cpp) and use that in > preference to > > anything else if it works. > > Do you mean `./configure' at build time? Or a post-install > script (in the sense of my above comment). Both. Cheers, Simon
RE: Preprocessor question
Simon Marlow <[EMAIL PROTECTED]> wrote, > > Please, can somebody explain, why the preprocessor is > > hardcoded in the GHC > > perl scripts? IIRC ghc (the perlscript itself) doesn't even reference > > $RAWCPP. mkdependHS and hscpp do, but why an absolute path > > and this obscure > > "-iprefix" parameter? Again, "-iwithprefix" is never used... > > > > Would it break things, if there is '$RAWCPP = "cpp > > -traditional"' only? > > It isn't strictly speaking hardcoded, it's set up when you configure a > binary distribution. So if you move gcc or install a new version, you need > to re-install ghc. I understand the technical issues, but the problem is that installing/compiling GHC from source is a *pain* (and requires you to have a machine with a lot of memory and a fast CPU or a spare machine, which you can afford doing nothing else for quite a while). So, IMHO, binary distributions are *very important* for GHC. I am sure that it is clear that a binary distribution with strict dependencies on locations of other tools is far from ideal. A (somewhat unsatisfactory) solution for package manager-based distributions (like .rpm or .deb) would be to use a post-install script that searches for cpp and patches the path. To make this easier, it would be nice if the path (and any other similar dependencies) where located in a dedicated file where they are easy to find and patch. > I suppose we can put in a configure test for known locations of cpp > (/lib/cpp, /usr/libexec/cpp, /usr/lib/cpp) and use that in preference to > anything else if it works. Do you mean `./configure' at build time? Or a post-install script (in the sense of my above comment). Manuel
RE: Preprocessor question
> Please, can somebody explain, why the preprocessor is > hardcoded in the GHC > perl scripts? IIRC ghc (the perlscript itself) doesn't even reference > $RAWCPP. mkdependHS and hscpp do, but why an absolute path > and this obscure > "-iprefix" parameter? Again, "-iwithprefix" is never used... > > Would it break things, if there is '$RAWCPP = "cpp > -traditional"' only? It isn't strictly speaking hardcoded, it's set up when you configure a binary distribution. So if you move gcc or install a new version, you need to re-install ghc. The reasons are pretty boring - - mkdependHS and friends need a cpp that accepts input on stdin, and files that don't end in ".c". That rules out 'gcc -E'. - many systems don't have a /lib/cpp (or any other easy way to get at cpp), or if they do it is just a synonym for 'gcc -E', which is no good. On some systems it lives somewhere else (eg. /usr/libexec/cpp on BSD4.4-derived systems). I suppose we can put in a configure test for known locations of cpp (/lib/cpp, /usr/libexec/cpp, /usr/lib/cpp) and use that in preference to anything else if it works. If anyone sends me a *complete* patch which does the right thing, then I'll incorporate it. Cheers, Simon
