X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
Date: Wed, 12 Jan 2005 08:38:57 +0200
From: "Eli Zaretskii" <eliz AT gnu DOT org>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-ID: <01c4f871$Blat.v2.2.2$89afa8c0@zahav.net.il>
Content-Transfer-Encoding: 7BIT
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 2.2.2
CC: bug-bison AT gnu DOT org
In-reply-to: <41E44BA6.16849.47FF9F7@localhost>
	(st001906 AT hrz1 DOT hrz DOT tu-darmstadt DOT de)
Subject: Re: ANNOUNCE: port of alpha bison-2.0
References:  <41E44BA6 DOT 16849 DOT 47FF9F7 AT localhost>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "Juan Manuel Guerrero" <st001906 AT hrz1 DOT hrz DOT tu-darmstadt DOT de>
> Date: Tue, 11 Jan 2005 21:56:54 +0200
> 
> The announce restriction to djgpp-workers is intentional.
> This is a port of the actual alpha release of bison.
> Starting with bison-1.35, the authors have decided to remove any support for
> non-posix systems like msdos/djgpp, MingW, etc. My patch for djgpp support
> for bison-1.875 has consequently been rejected but they offered my a djgpp
> directory to include all the djgpp specific files.
> Now, this port is the attempt to adapt the previous patch to the actual code
> and to the actual coding conditions.

Thanks for working on that.

Now, let me see if I understand: The package you put on
ftp.delorie.com has several files in its djgpp/ directory.  Of these,
only 4 files have any relation to the Bison sources:

 . the file `diffs' with minor patches to system.h and output.c
 . the files subpipe.[ch]

The rest are documentation and config.* files whose place is indeed in
a subdirectory (as you well know, several other GNU projects, which
did not drop DJGPP support, have these files in such a subdirectory).

The patches in `diffs' include, in addition to the equivalent of
subpipe.[ch], the following 2 small changes:

 . a 3-line patch to output.c that calls a function conditioned on
   HAVE_WORKING_VFORK and HAVE_WORKING_FORK being defined to zero.
 . a patch to system.h that removes a 2-line block conditioned by
   MSDOS and adds a different 2-liner conditioned by __DJGPP__.  The
   added block uses a Posix pathconf function to determine the value
   of TAB_EXT and OUTPUT_EXT macros.

Is this description accurate?

If it is, then I'm bewildered why similar patches were rejected by the
Bison maintainers.  The 3-line patch to output.c (actually, a one-line
patch if you don't count the preprocessor directives) is a no-brainer,
and is based on HAVE_* macros determined by the configure script, not
on ugly OS-dependent conditions; many GNU projects do that for systems
whose FORK implementation is buggy.  It is possible, with some minimal
effort, to rewrite djgpp/subpipe.[ch] files so that the result would
be usable on any reasonably portable platform that lacks a working
fork/vfork, not only on DJGPP.

system.h already has MSDOS-conditioned parts, so a claim that DOS,
MinGW and other non-Posix systems are ``not supported'' sounds
strange.  In any case, the __DJGPP__ condition could be removed and
the run-time definition using pathconf could be used on all platforms,
since pathconf is a Posix function, while relying on some minimal
file-name length being supported without checking first seems unwise
at best.

Could someone of the Bison maintainers please tell why Juan's patches
were rejected?  Would changing those patches in the sprit outlined
above be acceptable?