Date: Mon, 12 Nov 2012 12:12:44 +0100 From: Niclas Zeising <zeising@freebsd.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: Greg 'groggy' Lehey <grog@FreeBSD.org>, Koop Mast <kwm@FreeBSD.org>, freebsd-current@freebsd.org Subject: Re: Traditional cpp Message-ID: <50A0D9AC.9010503@freebsd.org> In-Reply-To: <509E3F53.4060609@FreeBSD.org> References: <201211090658.qA96whII081757@pozo.com> <20121109072631.GQ77848@eureka.lemis.com> <509CFC88.7050606@FreeBSD.org> <20121110064621.GA10902@eureka.lemis.com> <509E3F53.4060609@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A0D9AC.9010503>