On Wed, Jun 12, 2013 at 12:23:44AM +0200, Matthias Andree wrote: > Am 12.06.2013 00:11, schrieb Baptiste Daroussin: > > Hi, > > > > 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? >
To be more specific, some people have express some concern about the lack of support for traditional cpp in base, that's why I'm proposing this, now personnaly I don't care if tradcpp remains in ports (for imake, imake is not a matter of fixing imake, but rather all the users of imake). If we think it is not worth having a traditional cpp, I won't import it. cpp has not be design at first for this kind of usage, but someone of our vendors rely on a traditional cpp anyway. Just it exists, it is rather small, it is BSDL and actively maintainer, so :) concerning calendar(1) another approach is available here: bin/178463 regards, Bapt
pgpmRBOgMOwVs.pgp
Description: PGP signature
