WITHOUT_GCC flag disables installation of /usr/bin/cpp too --
is it Ok?
kaduk at MIT.EDU
Fri Sep 9 22:27:47 UTC 2011
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..
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.
> I think, it is good idea to exclude cpp from this list (but not from
> WITHOUT_TOOLCHAIN, of course).
More information about the freebsd-current