This is the mail archive of the
mailing list for the GCC project.
Re: A patch for Makefile.in
- To: law at cygnus dot com
- Subject: Re: A patch for Makefile.in
- From: Andi Kleen <ak at muc dot de>
- Date: 27 Jul 1998 16:37:14 +0200
- Cc: hjl at lucon dot org (H.J. Lu), egcs-patches at cygnus dot com
- References: <email@example.com>
Jeffrey A Law <firstname.lastname@example.org> writes:
> In message <m0yrPzn-000266C@ocean.lucon.org>you write:
> > cpp.1 is left out. Here is a patch.
> > --
> > H.J. Lu (email@example.com)
> > ----
> > Wed Jul 1 07:42:00 1998 H.J. Lu (firstname.lastname@example.org)
> > * Makefile.in (install-man): Install cpp.1.
> Don't we want to get away from having people calling cpp directly? If
> so, installing cpp.1 seems to be a step backwards.
> I'm open to thoughts & comments from the list on this topic.
I'm not sure why you want this. Some programs like imake or e.g. various
windowmanagers like fvwm or WindowMaker use cpp to preprocess their
configuration file. They don't care about C, they just want a minimal
preprocessor. Requiring them to always call gcc -E looks like a waste to
me, but it slows them down, requires them to add additional autoconf
tests just for this case [when I remember right the problem came just up
a few days ago in the WindowMaker list].
The preprocessor has a very stable specification and does not not change
as often as gcc itself, so I don't think most applications using it directly
need the flexibility of the gcc/'specs' interface.
So I would prefer if a link to cpp was installed in $execprefix/bin,
including a manpage.