On Fri, 9 Sep 2011, Benjamin Kaduk wrote: > 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. Another option may be to install devel/ucpp. I have not used it before, but it may be good enough for preparing ipfw scripts. Sean -- scf_at_FreeBSD.orgReceived on Fri Sep 09 2011 - 22:44:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:17 UTC