From owner-freebsd-current@FreeBSD.ORG Fri Sep 9 22:27:47 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A95E106566B for ; Fri, 9 Sep 2011 22:27:47 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id C9FE28FC0C for ; Fri, 9 Sep 2011 22:27:46 +0000 (UTC) X-AuditID: 12074422-b7ba7ae000000a14-98-4e6a92dc3569 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 28.46.02580.CD29A6E4; Fri, 9 Sep 2011 18:27:40 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p89MRjAn027682; Fri, 9 Sep 2011 18:27:45 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p89MRhpc011981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Sep 2011 18:27:45 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p89MRgHG024148; Fri, 9 Sep 2011 18:27:42 -0400 (EDT) Date: Fri, 9 Sep 2011 18:27:41 -0400 (EDT) From: Benjamin Kaduk To: Lev Serebryakov In-Reply-To: <1997790603.20110907212004@serebryakov.spb.ru> Message-ID: References: <1231707981.20110907201053@serebryakov.spb.ru> <4E67A720.2000903@FreeBSD.org> <1997790603.20110907212004@serebryakov.spb.ru> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-274034473-1315607261=:1411" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hTV1r0zKcvPYNM5NYs5bz4wWfSu2sjq wOQx49N8lgDGKC6blNSczLLUIn27BK6Mow/nsBacEqzYsKSHrYHxHW8XIyeHhICJxIPOg+wQ tpjEhXvr2boYuTiEBPYxSmxtncgE4axnlLh46xQLhLOfSeL8ktdgLUIC9RJrT69lBLFZBLQk pq88DWazCahIzHyzkQ3EFhFQlVj16AgriM0sYCjxct09sF5hgTCJ7Qe2sYDYnALWEge7n4H1 8go4SHxZOp0dYlkHo8Sj5ZvAGkQFdCRW75/CAlEkKHFy5hMWiKH+EtO+3WWawCg4C0lqFpIU hG0rcaNxFpStLXH/ZhvbAkaWVYyyKblVurmJmTnFqcm6xcmJeXmpRbqmermZJXqpKaWbGEEh ze6itIPx50GlQ4wCHIxKPLwrTbP8hFgTy4orcw8xSnIwKYnylk4ECvEl5adUZiQWZ8QXleak Fh9ilOBgVhLh3TYBKMebklhZlVqUD5OS5mBREufl2ungJySQnliSmp2aWpBaBJOV4eBQkuDN AMaukGBRanpqRVpmTglCmomDE2Q4D9DwMpDFvMUFibnFmekQ+VOMilLivDUgzQIgiYzSPLhe WMp5xSgO9IowbxpIFQ8wXcF1vwIazAQ0OGB7JsjgkkSElFQDY57ok0ded/ap/5mry19Xa6fQ XqwQ5LpWcpvLHZ6le950fGrZfvWO6t+Qa3OWTth4X/Zu0EWT+3wGZoLXVh08lBG3ZIZZbqJS 5rtZYhHH9GqaA126Zm4P1rjEm7DzVtbJBotTthoXnOuFJoj/4uv48qyi4IO40441qRKb13Pc jvX9r3YmMvgklxJLcUaioRZzUXEiAOFYGzgUAwAA Cc: freebsd-current Subject: Re: WITHOUT_GCC flag disables installation of /usr/bin/cpp too -- is it Ok? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 22:27:47 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-274034473-1315607261=:1411 Content-Type: TEXT/PLAIN; charset=windows-1251; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 7 Sep 2011, Lev Serebryakov wrote: > Hello, Dimitry. > You wrote 7 =F1=E5=ED=F2=FF=E1=F0=FF 2011 =E3., 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= =20 only required to emit output that its bundled C compiler will accept as=20 input. In particular, it can do whatever it wants with whitespace,=20 wrapping and unwrapping lines, outputting other spurious text, &c.. From=20cpp(1): The C preprocessor is intended to be used only with C, C++, and Obj= ec- tive-C source code. In the past, it has been abused as a general t= ext processor. It will choke on input which does not obey C's lexical rules. For example, apostrophes will be interpreted as the beginni= ng of character constants, and cause errors. Also, you cannot rely on= it preserving characteristics of the input which are not significant t= o C-family languages. If a Makefile is preprocessed, all the hard ta= bs will be removed, and the Makefile will not work. The (incredibly brain-dead) build system at $work runs cpp on a Makefile,= =20 which I had to hack around in order to get things to work. It's really an= =20 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=20 something that was designed as a general-purpose macro processor (e.g.=20 m4(1) which is in base) -- abusing cpp(1) is just asking for weird/subtle= =20 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). ---559023410-274034473-1315607261=:1411--