Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Date: Thu, 11 Oct 2001 18:17:00 -0400 From: Christopher Faylor To: cygwin-apps AT cygwin DOT com Subject: Re: Packaging cURL for cygwin distribution ??? Message-ID: <20011011181700.F3488@redhat.com> Reply-To: cygwin-apps AT cygwin DOT com Mail-Followup-To: cygwin-apps AT cygwin DOT com References: <6EB31774D39507408D04392F40A10B2BC1FD6C AT FDYEXC202 DOT mgroupnet DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6EB31774D39507408D04392F40A10B2BC1FD6C@FDYEXC202.mgroupnet.com> User-Agent: Mutt/1.3.21i On Thu, Oct 11, 2001 at 06:00:03PM -0400, Roth, Kevin P. wrote: >There exists a command-line http (and ftp, and more) client >called cURL (along with its back-end library named libcurl) >that I would like to see added to the cygwin setup.ini. I >realize there's a moratorium in effect on new packages, and >I'm happy to simply post an announcement to the Software >listing on www.cygwin.com. (for now ;-) > >Before I do that, I have a question: > >cURL's configure script includes an option "--disable-shared". >I *think* "--enable-shared" is the default, however I don't >really understand exactly what these options mean. > >Is there any best practice about whether or not these options >should be used for cygwin builds? > >I've built it both ways, and it seems to run just fine (under >cygwin as well as directly from DOS) in both configurations. What kind of shared libraries does it produce? I don't think that it really matters either way. Personally, I'd have a preference for the default configuration, though. >For what it's worth: > >a: I ran a search on the cygwin-apps archive, and didn't > find any reference to curl. Thus, I assume no one > else is already working on this. > >b: Because cURL already compiles (and tests) cleanly under > cygwin, I expect no great difficulty in creating binary > and source tarballs, however I haven't actually done so yet. This sounds like a good candidate for a new cygwin package once the moratorium has been lifted, which should be soon if I can get off my butt and finish up some stuff. It would make sense for you to bundle up a standard package and offer it on the cygwin.com software section. And, maybe even announce it in cygwin AT cygwin DOT com . Then you might get a little feedback before it becomes an official cygwin package. Btw, thank you for a well-researched and on-topic contribution to cygwin-apps. I think this is your first post and you got everything right! cgf