Re: DJGPP support for bison

[Juan Manuel Guerrero]

Subject:       Re: DJGPP support for bison
From:          Tim Van Holder <address@hidden>
To:            Juan Manuel Guerrero <address@hidden>
Cc:            address@hidden
Date:          30 Jan 2002 16:04:05 +0100

Hi Tim,

On Wed, 2002-01-30 at 16:04:05 , Tim Van Holder 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?

No one. Except that I usually try to use ansi/posix functions instead of
djgpp specialities. Netherless, if you prefer to code this in a different
way it will be ok with me. I do not care to much about the way the 
functionality is
coded as long as it is well done and it works.

>  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).

IMHO this is not a good idea. Out-of-the-box configuration almost always implies
LFN support and this implies the access to some kind of Win9X. This will exclude
all users of old DOS or clones like freedos (DJGPP is a dos compiler and not a 
WIN32 one).
AFAIK this would be against the design rules of DJGPP. To make the point clear,
I personally have _no_ preferences concerning this issue, but IMHO it is not 
worth
to exclude a part of the DJGPP users only to avoid the arch/djgpp stuff. It 
should be
clear that a gnu package will never be configurable and compilable 
out-of-the-box
without LFN support. If the djgpp-workers want to support plain DOS, then some
kind of config.bat, config.sed, etc must be supplied.
Please note that I have preferences. I am only following the design rules of 
DJGPP ports.
Because I upload bsnNNN[bds].zip files to simtel.net anyway it is not a great 
inconveniece
to me to add a /djgpp subdir containing the needed files for configuring and 
compiling
on plain DOS.

> 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).

Yes, I agree.
In previous ports, I have disabled the DOSish code completely with:
   #if (defined (MSDOS) && !defined (__DJGPP__)) || defined (_WIN32)
IMHO that is the best approach to this issue.

> + #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.

I agree. This was simply a mistake.

Regards,
Guerrero, Juan Manuel