bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DJGPP support for bison


From: Tim Van Holder
Subject: Re: DJGPP support for bison
Date: 30 Jan 2002 16:04:05 +0100

Hi Juan,

On Wed, 2002-01-30 at 15:22, Juan Manuel Guerrero wrote:
> modifications to system.h, files.c and getargs.c are needed. The DJGPP
> port uses pathconf() to detect at runtime the file system in use. Also
> Win9X is case sensitive, so a DJGPP port of bison should not allow

Any particular reason why you use pathconf instead of _USE_LFN?

> sed or grep that come with build-in DJGPP support. The files created are:
>   arch/djgpp/config.bat
>   arch/djgpp/config.in
>   arch/djgpp/config.site
>   arch/djgpp/readme.in
>   arch/djgpp/Makefile.am

Ouch.  First of all, none of this should be needed; bison comes with a
configure script created by a recent autoconf that should work
out-of-the-box for DJGPP.  Additionally, distributing your own
config.site and forcing its use is VERY likely to break configuration
entirely.  Only a config.site provided by our bash or autoconf package
should be used.
That leaves only the README as a (potentially) needed file, and I'm not
sure it's worth it to add arch/djgpp just for that file (esp. since
bison should build out-of-the-box, especially after your source
patches).

> 2) files.c
> 2.1) skeleton_find()
> To solve this difficulty I have changed the code from:
> 
>   #if defined (MSDOS) || defined (_WIN32)

IIRC, simply disabling this code entirely for DJGPP should do the trick.
I don't think we should support the DOS/Win-specific INIT envvar at all;
DJGPP is supposed to be a Unixy platform (albeit with DOSish roots).

> + #if defined (__DJGPP__)
> + # ifndef BISON_SIMPLE
> + #  define BISON_SIMPLE "/dev/env/DJDIR/share/bison.simple"
> + # endif
> + # ifndef BISON_HAIRY
> + #  define BISON_HAIRY "/dev/env/DJDIR/share/bison.hairy"
> + # endif
> + #endif
> + 

These variables already get defined to $prefix/blah, so this should be
entirely unnecessary (in fact, this would produce an incompatibility in
layout, as recent bison put these in share/bison, not share).
DJGPP has historical reasons to want these in share instead, but that
should not concern bison.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]