WITHOUT_GCC flag disables installation of /usr/bin/cpp too -- is it Ok?

[Benjamin Kaduk]

On Wed, 7 Sep 2011, Lev Serebryakov wrote:

> Hello, Dimitry.
> You wrote 7 сентября 2011 г., 21:17:20:
>
> I think, that /usr/bin/cpp is valuable by itself, as it is handy
> generic preprocessor tool, useful for preparing complex ipfw scripts,
> for example. All others are bundled together, for sure.

I am not really convinced.  /usr/bin/cpp is the C preprocessor, and it is 
only required to emit output that its bundled C compiler will accept as 
input.  In particular, it can do whatever it wants with whitespace, 
wrapping and unwrapping lines, outputting other spurious text, &c..
From cpp(1):
        The C preprocessor is intended to be used only with C, C++, and Objec-
        tive-C source code.  In the past, it has been abused as a general text
        processor.  It will choke on input which does not obey C's lexical
        rules.  For example, apostrophes will be interpreted as the beginning
        of character constants, and cause errors.  Also, you cannot rely on it
        preserving characteristics of the input which are not significant to
        C-family languages.  If a Makefile is preprocessed, all the hard tabs
        will be removed, and the Makefile will not work.
The (incredibly brain-dead) build system at $work runs cpp on a Makefile, 
which I had to hack around in order to get things to work.  It's really an 
ugly hack, though, and is not at all robust.  I wish I didn't have to.

If you want a general-purpose macro processor, please consider using 
something that was designed as a general-purpose macro processor (e.g. 
m4(1) which is in base) -- abusing cpp(1) is just asking for weird/subtle 
errors to be introduce in the future.

-Ben Kaduk

>
> I think, it is good idea to exclude cpp from this list (but not from
> WITHOUT_TOOLCHAIN, of course).