Date: Tue, 20 Nov 2001 15:00:41 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Andrew Cottrell" Message-Id: <2950-Tue20Nov2001150040+0200-eliz@is.elta.co.il> X-Mailer: emacs 21.1.50 (via feedmail 8 I) and Blat ver 1.8.9 CC: djgpp-workers AT delorie DOT com In-reply-to: <007d01c171b5$8ee89130$0a02a8c0@acceleron> (acottrel@ihug.com.au) Subject: Re: GNU Grep alpha release 2.5e References: <000d01c170ed$a6f46880$0a02a8c0 AT acceleron> <007d01c171b5$8ee89130$0a02a8c0 AT acceleron> 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: "Andrew Cottrell" > Date: Tue, 20 Nov 2001 22:21:23 +1100 > > I downloaded the CVS 2.5f code as this was suggested by the current Grep > maintainer that this may fix the it. I now get past the HAVE_LIBPCRE and now > find that DJGPP does not have support for S_ISSOCK(stats->stat.st_mode) > which was introduced in the changes since 2.5e. Should I get arround this by > defining it out for DJGPP as per the change below or define it in sys\stat.h > to always be false such as:- > #define S_ISSOCK(m) (0x00) None of the above, IMHO. S_ISSOCK is not sufficiently portable (even though the latest draft of Posix requires it) for programs to use it freely. I think Grep should only use S_ISSOCK if it is defined, not only for DJGPP. > > I have a few questions about this:- > > 1) Should I delete the redundant files in the DJGP directory? > > 2) Should I move the djgpp\readme file to the main grep directory and > > rename it to readme.dos? > > 3) Is there any problem as "releasing" this as an alpha release for > > DJGPP? By releaseing I mean put it on the main html page at clio and put > the > > sources and binary files to the incoming directory at delorie.com? (I need > > to build a 2.03+ DJGPP setup on my Win 98 PC before I can produce the > binary > > files to send ) > > 4) Are important are the documentation zip files? > > Anyone disagree with the following suggestions:- > 1) Yes Agreed; but please make sure what you delete is indeed redundant ;-) > 2) Yes This is up to the package maintainer. > 3) No Maybe, I don't know. Are there any significant user-level changes in this versions as compared to 2.4? In any case, if you can test the build on a non-LFN platform, it's highly recommended. > 4) Unknown. Not very important, but if you have the time to produce them and the bandwidth to upload them, why not?