Csup cvsmode build discussion

[Bob Bishop]

Hi,

On 16 Jan 2008, at 09:33, Ulf Lilleengen wrote:

> Hello hackers,
>
> As some might know, I've been implementing CVSMode for csup over the  
> last couple
> of months. Right now, I'm quite close to have it work (does not mean  
> it will
> work perfect :)), but I encountered some issues regarding the  
> inclusion of my
> lex and yacc files that I would like to discuss. It is assumed that  
> the reader
> know what lex and yacc is.
>
> First of all, I implemented the RCS parser required to operate on  
> RCS files
> using lex and yacc. Those are in FreeBSD userland, but the problem  
> is they are
> wayy to outdated for csups need.  The reason is mainly because they  
> don't
> support:
> 1) reentrancy (needed since csup uses two threads, one to send  
> information
> to the server regarding it's files, and one to recieve information  
> on how a file
> is to be updated).
>
> 2) prefixing of lex/yacc output. Not a big deal, but easy if one  
> doesn't need to
> have to work around it.
>
> 3) parameter passing. Part of the reentrancy requirement but useful  
> if one would
> extend the arguments to a parser.
>
> Because of this, I've been compiling the parser and tokenizer with  
> the help of bison
> and flex from ports.
>
> Now, the base system already have flex, but the flex version in base  
> is heavily
> outdated (version 2.5.4 versus 2.5.34 in ports) and does not support  
> reentrancy.
> Is there a reason why it's outdated? What I can think of is that it  
> is either
> unmaintained, or that developers want it to disappear from base.
>
> The yacc version in base is pretty old too and does not support  
> reentrancy. I
> would like to not have to hack it up to support this to avoid using  
> bison, (And
> I suspect importing bison into base is going to happen over someones  
> dead
> body :)).
>
> So, I'm asking you, how should I best deal with this? Should I
> a) Just include the _generated_ parser and tokenizer (e.g the output  
> from bison
> and flex) and just include the yacc and lex files in case someone  
> wants to work
> more on it?
>
> b) Modify parser to be non-reentrant and solve my issues with locks.
>
> c) Import bison into base and update flex version.
>
> d) <Insert your fantastic idea here>
>
> Alternative 'a' is my favorite, and seems to be the easiest way to  
> avoid a heavy
> inpact on the base system, but again it will complicate procedure of
> modifying the parser since one have to use the correct build tools  
> etc. 'b'
> would lead to performance loss and I would very much like to avoid  
> it. 'c'
> would take a lot of work and I think many would protest on importing  
> bison
> (including me if I were not biased with needing it and all :))
>
> What I ask of you is comments on these alternatives as well as  
> inserting your
> fantastic idea if you happen to have one :)

I'm not going to comment on the merits of flex and bison as I like to  
be polite :-)

I'd suggest (a), but package the yacc and lex source files up as a  
port so that they are in CVS and can readily be rebuilt if necessary.

Why do you want prefixing? And precisely what do you want to do with  
parameters?

--
Bob Bishop          +44 (0)118 940 1243
rb at gid.co.uk fax +44 (0)118 940 1295