Shantonu Sen <[EMAIL PROTECTED]> writes:
> Did either AIX or solaris have a problem with the lexed version
> dtimep.c which is in CVS? hopefully that's ANSI C.
It worked fine on AIX (4.1). IIRC, Solaris succeeds in lex'ing the file, so
I've never tried the pre-canned one on it.
> > Actually, it's probablly a good idea to keep the .c file in the
> > distribution and generate it only if $(LEX) is defined in the
> > Makefile. That way, users won't necessarily have to install flex
> > if their system doesn't already have some lexer.
> >
> > Going a step further, just keep a flex-lexed .c version available,
> > and only re-lex it if the installed $(LEX) is actually flex. Doing
> > so would somewhat avoid the compatibility problems above. And unlike
> > the old reliance on AT&T lex, it's actually possible to get flex
> > and install it if it doesn't come with your system.
>
> Is it necessary to re-flex it even if flex is present? what would
> change from host to host that would make a locally-done flex more
> compatible or useful? if flex on my home machine generates good,
> portable C, what is the incentive?
Is the C it generates guaranteed to be portable? I thought OS-specific
stuff gets into the generated code (e.g. signedness of char and whatnot).
I agree with Doug that it's reasonable to have dtimep.lex use flex-specific
features. If the user has flex installed, we'll run it to make sure
dtimep.c is correct for the given OS. If flex isn't installed (even if lex
is), we'll use the pre-canned dtimep.c and hope for the best.
It'd be nice to be lex compatible, but flex is so easy to download and
install, I'd say as long as we document the flex pseudo-requirement, that's
fine.
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
[EMAIL PROTECTED] | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
