Re: Traditional cpp

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