Date: Sun, 7 Mar 1999 17:17:16 -0500 (EST) From: Bill Fumerola <billf@jade.chc-chimes.com> To: "Kenneth D. Merry" <ken@plutotech.com> Cc: committers@FreeBSD.org, ports@FreeBSD.org Subject: Re: getopt Message-ID: <Pine.BSF.3.96.990307171442.19975A-100000@jade.chc-chimes.com> In-Reply-To: <199903071820.LAA73812@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 7 Mar 1999, Kenneth D. Merry wrote: > > 'getopt' is not included in the base tree (it's a GNU thing) and many > > ports depend on it. There have been proposed solutions to fix this > > (ports/8838), but none of them feel right to me. > > getopt(3) is included in the base tree. It's in libc. It isn't GNU getopt, > though. [This is to Nate too] I meant getopt_long or whatever the linux 'addon' was, I know getopt is libc. > > Would the best solution be rolling a getopt library and then making it a > > port? Should I proceed with this? > > I think that any port that just assumes that the system getopt is GNU > getopt is making a bad assumption. I suppose the ports in question are > probably Linux-based, 'eh? Yes. Portablity isn't something most programs created in Linux seem to care about recently. > > NOTE: I am not talking about /usr/src/usr.bin/getopt, I am talking about: > > bash-2.01$ pwd ; ls getopt* > > /usr/src/gnu/usr.bin/diff > > getopt.c getopt.h getopt1.c > > > > Comments? I'd hate to do this the wrong way. > > Well, I suppose that making it a port is probably the most acceptable > solution. Don't just go on my opinion, though...see what other folks have > to say. - bill fumerola - billf@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfumerol@computerhorizons.com - billf@FreeBSD.org - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990307171442.19975A-100000>