Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com content-class: urn:content-classes:message Subject: RE: setup changes to build standalone MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 Apr 2002 15:11:53 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Robert Collins" To: "Charles Wilson" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g3Q5C0f25999 > -----Original Message----- > From: Charles Wilson [mailto:cwilson AT ece DOT gatech DOT edu] > Sent: Friday, April 26, 2002 2:12 PM > https://sourceforge.net/projects/mingwrep/ Thanks. > >>I wonder if we need a "mingw-libs" package. > >> > > > > Yes, please, please, yes. I would really really love it if > some of the > > common libs (zlib, bz2lib, stdc++) where available in a setup.exe > > installable pacakge. > > > Yes, I like this too -- but I'm nervous about it growing ridiculously > large. What if (eventually) setup.ini turns into XML? Do we put a > mingw build of libxml into 'mingw-libs'? How far does this go? > (visions of full{mingw}.exe) glib + foo + bar + ... If this sort of expansion were to occur, I'd suggest we take the split-setup option and have a bootstrapping setup that is essentially what we have today, but is only run once - ever. Then after that a maintenance setup that is able to use cygwin linked tools. > OTOH, we've already discussed (and discarded, thank g-d) the idea of > (for instance) the zlib maintainer providing both a > cygwin-setup-installable zlib package (/usr/bin/cygz.dll, > /usr/lib/libz.[dll|a]) and a cygwin-setup-installable > mingw-zlib package > (/usr/bin/mgwz.dll, /usr/lib/mingw/libz.[dll|a]). Ditto > bzip2, libxml, > ... we are not a mingw-porting factory. Agreed. > whatever happened to the idea of an official cygwin package, that > contained a true cygwin-host, mingw-target cross compiler? Didn't > somebody or other volunteer to provide that? I recall Danny talking about a gcc v 3.1 for April, but I'm not sure if he meant as a cygwin package or as something else... > > It really depends on what you want to do. Some stuff it does > > spectalularly well, some things it has trouble with. With the 'cross > > compiling but not' approach, it would almost certainly have > some trouble > > :}. > > see above, true cross compiler... Yup. In fact gcc -mno-cygwin is close enough that automake won't be confused... as long as it's told --host= :}. Rob