Re: A patch for Makefile.in

[Andi Kleen <ak at muc dot de>]

On Mon, Jul 27, 1998 at 07:18:59PM +0200, Jeffrey A Law wrote:
> 
>   In message <19980727191235.A1438@kali.lrz-muenchen.de>you write:
>   > But see the rest of my message. Lots of programs use cpp for non-C
>   > text files, and they don't need the sophisticated specs file handling.
>   > Most Unix systems supply a cpp somewhere in the standard $PATH, it just
>   > does not work on gcc based systems. 
> Right, but many do depend on some predefines.  And while they do not
> need complex specs handling, they often need some specs handling.
> 
> Calling cpp directly, IMHO, is bad and we should not encourage folks to
> do so.
> 
> And, actually, cpp has generally *not* been in a standard $PATH
> location.  Most code expects to find it in /lib or /usr/lib, which
> are generally not in one's path.

The idea was that if gcc installed it per default in $(execprefix)/bin then 
a simple symlink would suffice for that. Currently it is a pain to keep
the /lib/cpp link up to date with the varying gcc-lib/.../../ directory
names.

Another argument in favour of installed cpp: as I pointed out many 
non-development packages use cpp to preprocess configuration files. E.g. in 
many Linux distributions "cpp" is therefore a separate package from gcc
to not require a user who just needs cpp to run e.g. his Window Manager to 
install the complete compiler. A setup to install cpp and cpp.1 per default
would make the packaging scripts easier, and the paedagogical effect you
were hoping for is non-existent on these distributions anyways @)

In the Linux case it would be very confusing for the user when some
distributions allow to call cpp directly from the PATH, and others need
gcc -E. 

-Andi