From owner-freebsd-current@FreeBSD.ORG Mon Nov 12 11:12:58 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B82A44E; Mon, 12 Nov 2012 11:12:58 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7D4688FC0C; Mon, 12 Nov 2012 11:12:57 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id CC6684000F; Mon, 12 Nov 2012 12:12:55 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id C1B2740008; Mon, 12 Nov 2012 12:12:55 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (h-45-105.a163.priv.bahnhof.se [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 44AE540003; Mon, 12 Nov 2012 12:12:54 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y0TpY55SDz8hVn; Mon, 12 Nov 2012 12:12:53 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id jW9aM9hdvObE; Mon, 12 Nov 2012 12:12:50 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y0TpV3NPLz8hVm; Mon, 12 Nov 2012 12:12:50 +0100 (CET) Received: from [IPv6:2001:470:dca9:1::3] (celes.daemonic.se [IPv6:2001:470:dca9:1::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 3Y0TpT6BBWz9Ctj; Mon, 12 Nov 2012 12:12:49 +0100 (CET) Message-ID: <50A0D9AC.9010503@freebsd.org> Date: Mon, 12 Nov 2012 12:12:44 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: Traditional cpp References: <201211090658.qA96whII081757@pozo.com> <20121109072631.GQ77848@eureka.lemis.com> <509CFC88.7050606@FreeBSD.org> <20121110064621.GA10902@eureka.lemis.com> <509E3F53.4060609@FreeBSD.org> In-Reply-To: <509E3F53.4060609@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Greg 'groggy' Lehey , Koop Mast , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Mon, 12 Nov 2012 11:12:58 -0000 On 2012-11-10 12:49, Dimitry Andric wrote: > On 2012-11-10 07:46, Greg 'groggy' Lehey wrote: >> On Friday, 9 November 2012 at 13:52:24 +0100, Dimitry Andric wrote: > ... >>> Looks like yet another cpp -traditional abuse. >> Use or abuse? > > Abuse, definitely. :-) A "C Preprocessor" is clearly meant to > preprocess C, not arbitrary text files. Hear, hear! :) > > You can see the problem of this approach, when you try to use another > traditional preprocessor, like ports/devel/ucpp, for tools like Imake. > Niclas Zeising can probably tell some interesting stories about this. > > Any subtly different spacing, token parsing behaviour, etc. tend to > break those tools. They are basically relying on the specifics of the > GNU cpp implementation. I have not tried imake, but when using ucpp for other parts of the xorg bundle, most notably libX11, things broke. ucpp passed the configure check, but when used to format text files it does not seem to work the same as gnu cpp (unless you have to add some sort of command line flag that I'm unaware of). This had the unfortunate effect that locales in xorg, amongst other things, stopped working. What I ended up doing to get the xorg ports to build (at least the ports pulled in by the xorg meta port) was to simply remove the configure check for cpp -traditional, and proceed anyway. The only ill effects I've seen so far is that whitespace in cpp generated files get mangled. I have not noticed any functional problems though. For details, see ports r301687: http://svnweb.freebsd.org/ports?view=revision&revision=301687 As a side note, it seems that xorg upstream is moving away from using cpp to generate manuals, at least. For the case of imake the issue might be harder to resolve. I don't know any imake internals, and I have never used it, but it seem to me that imake uses cpp to generate and pre-process makefiles. This might be harder to fix by replacing cpp with sed/awk wizardry. It might be more worthwhile to try to fix the port that use imake to use something else, but I have no clue about how big an undertaking this would be. > > >> In any case, it's not the only one. In the Good Old >> Days people did things like that. So, it seems, does imake, and I'm >> sure others will come out of the woodwork. >> >>> Clang will most likely never support traditional preprocessing. >> >> OK. >> >>> It is probably better to just use sed or awk for this kind of >>> trickery. >> >> I'm not sure that's the way to go. It's more work than it's worth. >> >> What we really need is a traditional cpp. That's not difficult: >> there's one in 4.3BSD (all 32 kB of source). OpenBSD also had one, >> though it's gone now, so presumably that one has a clean license. >> Both appear to be from pcc. Should we import it into the tree as, >> say, tradcpp? > > Please check with Niclas and the other ports guys who have been > wrestling with exactly this issue for some time. They may have lots of > good suggestions. I have not tested anything but gnu cpp, clang cpp and ucpp. I'm not against the import of a traditional cpp, but to me it seems it might be better to just fix the cpp abuse altogether. In any case, the cpp -traditional replacement *must* be bug-for-bug compatible with gcc cpp, which I've been told is quite undocumented. Regards! -- Niclas