Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Jun 2013 00:56:54 +0200
From:      Jilles Tjoelker <jilles@stack.nl>
To:        Matthias Andree <matthias.andree@gmx.de>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Importing tradcpp (traditional (K&R-style) C macro preprocessor) into base?
Message-ID:  <20130611225653.GB82810@stack.nl>
In-Reply-To: <51B7A370.3010307@gmx.de>
References:  <20130611221124.GC84600@ithaqua.etoilebsd.net> <51B7A370.3010307@gmx.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 12, 2013 at 12:23:44AM +0200, Matthias Andree wrote:
> Am 12.06.2013 00:11, schrieb Baptiste Daroussin:
> > I have been working in importing tradcpp (developped by David A.
> > Holland from NetBSD) into the ports tree, it is a traditional
> > (K&R-style) C macro preprocessor BSD licensed. I first worked on it
> > so that imake can work properly without gcc.

> > I discovered that some part of the base system still needs a
> > traditional preprocessor, like (calendar), what I propose it to
> > import tradcpp into the base system (not the version in port right
> > now but what will become version 0.2).

> > It mostly behave like gcpp, and I'm able to properly use calendar
> > along with tradcpp with this small patch:
> > http://people.freebsd.org/~bapt/tradcpp.diff

> > Any objections against me importing it?

> Shouldn't we fix calendar and imake so that they can use a modern cpp,
> instead of going back 25 years?  Or am I missing the point here?

A modern cpp is only suitable for preprocessing C code. It makes various
assumptions about syntax that make it work better for preprocessing
actual C code but worse for text that is not C. Calendar and imake use
the traditional cpp for preprocessing non-C text.

There is already a patch for removing the dependency on cpp in calendar.
I think that makes more sense than importing a traditional cpp (assuming
there are no other users in base that cannot be fixed).

The "fix" for imake is probably not to use it. Ports that need imake can
continue to use it if it depends on a traditional cpp port.

A further point of confusion is that things that want a "traditional
cpp" in fact want an equivalent of "gcpp -traditional". This is in fact
the point of tradcpp and why the old preprocessors do not work.

-- 
Jilles Tjoelker



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130611225653.GB82810>