Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Mail-Followup-To: gcc AT gcc DOT gnu DOT org, gdb AT sources DOT redhat DOT com, binutils AT sources DOT redhat DOT com, cygwin AT sources DOT redhat DOT com, dj AT delorie DOT com From: Ian Lance Taylor To: DJ Delorie Cc: gcc AT gcc DOT gnu DOT org, gdb AT sources DOT redhat DOT com, binutils AT sources DOT redhat DOT com, cygwin AT sources DOT redhat DOT com Subject: Re: Another RFC: regex in libiberty References: <200106080127 DOT VAA01308 AT greed DOT delorie DOT com> <200106080134 DOT VAA06362 AT envy DOT delorie DOT com> Date: 07 Jun 2001 18:43:10 -0700 In-Reply-To: <200106080134.VAA06362@envy.delorie.com> Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii DJ Delorie writes: > > gdb already ships with gnu-regex.c. Why not just move that to > > libiberty? > > Because gdb, tcl, expect, cygwin, and gcc each have a copy of regex, > and they're all different. Which to choose? The ones in gdb and gcc are basically the same. TCL and Expect are not GNU projects, and will continue to have their own regex code. Cygwin has different licensing constraints; cygwin already has its own copy of getopt, for instance. > > I can't see any reason for a BSD-licensed regex in libiberty. > > libiberty already GPL code. > > Any regex added to libiberty becomes part of newlib and cygwin as > well, and those projects are sensitive to GPL vs non-GPL licensing > issues. I see no reason to confuse the regex in libiberty with the regex in newlib and cygwin, any more than there is to confuse the getopt in libiberty. regex in libiberty should satisfy the needs of GNU tools, and as such I think it is appropriate to use the GNU regex. Of course, if the GNU regex is inferior, then it might make sense to choose something else. But I don't think we should avoid using GNU code for GNU tools because of licensing issues for non-GNU tools. Ian -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple