This is the mail archive of the
mailing list for the GCC project.
Re: cpp replacement
- To: law at cygnus dot com
- Subject: Re: cpp replacement
- From: Manfred Hollstein <manfred at s-direktnet dot de>
- Date: Wed, 3 Mar 1999 13:35:47 +0100 (MET)
- Cc: zack at rabi dot columbia dot edu, egcs-patches at cygnus dot com
- References: <firstname.lastname@example.org>
- Reply-To: manfred at s-direktnet dot de, mh at exept dot de
On Tue, 2 March 1999, 00:43:30, email@example.com wrote:
> In message <199902010324.WAA23294@blastula.phys.columbia.edu>you write:
> > On Sun, 31 Jan 1999 12:45:16 -0700, Jeffrey A Law wrote:
> > >
> > >When y'all have settled on the script, can you send a patch which includes
> > the
> > >cpp script and the Makefile.in changes to get the script installed?
> > >
> > >We actually wanted to include this kind of script in egcs-1.1, but it fell
> > >through the cracks.
> > Here's my patch. It should work correctly on all supported Unixes,
> > but I doubt it works on cygwin/mingwin/djgpp. Shouldn't be too hard
> > to fix, just gotta find someone who knows how you get shell scripts to
> > be executable under DOS.
> > zw
> > 1999-01-31 22:22 -0500 Zack Weinberg <firstname.lastname@example.org>
> > * cpp.in: New file.
> > * Makefile.in (install-driver): Also install cpp wrapper in
> > $(bindir).
> > (xcpp): New target.
> I think I like HJ's old cpp patch better. It seems a lot more complete for
> the kinds of problems we're trying to address.
> Specifically it handles installing cpp in a second location, which helps with
> the "/lib/cpp" problem (lots of stuff hard-codes /lib/cpp :(
> It also handles install/uninstall better (we really ought to fix uninstall
> one day, several folks have asked about it).
> HJ's patch has got a few minor problems, but nothing I shouldn't be able
> to resolve on the fly.
> I do have one question, why does your patch bother with argument processing?
> cpp's interface has always been: cpp [switches] [infile] [outfile]
> where infile and outfile default to stdin/stdout automatically. Does gcc -E
> not handle input on stdin or something like that?
IIRC, the whole thread started because "cpp" alone does no longer
define the same machine/os specific macros that "gcc -E" does; e.g.
"i386", desperately needed by "Imake", was missing. So we decided
to use "gcc -E" instead. This needs some tweaking due to the following:
1. Running "gcc -E" with input from stdin gives:
$ echo "abc" | gcc -E -Dabc=xyz
gcc: No input files
Appending a single "-" results in the exepted:
# 1 ""
2. When such a wrapper script would be used for preprocessing
files with unknown extensions (e.g. the calendar application
"plan" processes its "~/.holiday" file with "cpp"), this
will result in annoying error message from the linker as in:
$ gcc -E .holiday
gcc: .holiday: linker input file unused since linking not done
With '-x c' added, gcc will simply call "cccp" and then terminate
instead of "passing the unknown file to ld".
I don't know exactly, how Zack's script looks like, but provided that
"cccp" and "gcc -E" don't necessarily define the same macros, the wrapper
script should consider the above two issues.