delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2005/01/12/17:41:53

X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
From: "Juan Manuel Guerrero" <st001906 AT hrz1 DOT hrz DOT tu-darmstadt DOT de>
Organization: Darmstadt University of Technology
To: djgpp-workers AT delorie DOT com
Date: Wed, 12 Jan 2005 23:40:48 +0200
MIME-Version: 1.0
Subject: Re: ANNOUNCE: port of alpha bison-2.0
Message-ID: <41E5B580.22330.4DEAFBA@localhost>
In-reply-to: <01c4f871$Blat.v2.2.2$89afa8c0@zahav.net.il>
References: <41E44BA6 DOT 16849 DOT 47FF9F7 AT localhost> (st001906 AT hrz1 DOT hrz DOT tu-darmstadt DOT de)
X-mailer: Pegasus Mail for Windows (4.21c, DE v4.21c R1)
X-TUD-HRZ-MailScanner: Found to be clean
X-TUD-HRZ-MailScanner-SpamCheck:
X-MailScanner-From: st001906 AT hrz1 DOT hrz DOT tu-darmstadt DOT de
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

First, I will not send the bison-2.0 patch to the bison maintainers
until it has not been tested by the djdev204/winxp users. This implies
that they have still not seen the new patch at all and possibly can not
comment it.


On Wed, 12 Jan 2005, Eli Zaretskii wrote:

> 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?

Yes. The changes proposed in system.h and output.c are minimal and are
the same in both patches, the one for bison-1.875 and the other for bison-2.0.
The great difference concern the files subpipe.[ch]. In the bison-1.875
patch all the djgpp specific code has been inserted into the original /lib/subpipe.[ch]
files using code like that this:

#if HAVE_WORKING_VFORK || HAVE_WORKING_FORK
/*
 *  Here are all the *original* and *unaltered* posix functions: 
 *
 * init_subpipe()
 * create_subpipe()
 * reap_subpipe()
 */
#else /* !HAVE_WORKING_VFORK && !HAVE_WORKING_FORK */
# if __DJGPP__
/*
 *  Here are all the djgpp specific versions of the posix functions: 
 *
 * init_subpipe()
 * create_subpipe()
 * reap_subpipe()
 */
# else /* !__DJGPP__ */
#  error "vfork, fork or an emulation is required."
# endif /* !__DJGPP__ */
#endif /* !HAVE_WORKING_VFORK and !HAVE_WORKING_FORK */

This has been objected because it introduced new non-posix code to the
bison sources that needs to be maintained. This was the reason for their
proposition to create a djgpp subdir that should contain the djgpp stuff.
This was ok with me so I have removed all djgpp specific code from the
/lib/subpipe.[ch] and created djgpp specific replacements for these files
in the /djgpp subdir. Please note that the issue is not the djgpp specific
code itself. The issue is that they do not like to see that djgpp specific
init_subpipe(), etc. code included in their posix /lib/subpipe.[ch]. There
are no objections against djgpp code if it is placed in separeted files like
the /djgpp/subpipe.[ch]. I assume that the small changes to system.h and
output.c will be accepted.


> system.h already has MSDOS-conditioned parts, so a claim that DOS,
> MinGW and other non-Posix systems are ``not supported'' sounds
> strange.

Neitherless it is true. That there is still one single MSDOS-conditioned
(really minimal) code does not imply that the non-posix/msdos support has
not been dropped. The non-posix support has effectivly been dropped the day
as the use of fork or vfork has been decided. In those days (a couple of
years ago) before they start their codinh effortsI suggested to the maintainers
the use of posix_spawn* family of functions but that has been rejected.

In conclusion, the maintainers/authors of bison have decided to convert
bison in a posix tool that requires the use of a posix system to be 
compiled and used. Althoogh I am still in the bison member list I am not
directly involved with the bison developement so I do not comment that
politics. Due to this fact, they are not objecting the distribution of non-
posix files like /djgpp/subpipe.[ch] in the official distribution but they do
not want to see their code to be modified with non-posix code like the
djgpp specific one.


On Tue, 11 Jan 2005, Frank Donahoe wrote:

> No problems were encountered building and testing alpha bison-2.0
> using djgpp 2.04 on Windows XP home edition.

Thanks.


> Below are corrections/suggestions for the readme file.

Applied.


Regards,
Juan M. Guerrero

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019