From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4691 invoked by alias); 20 Jun 2013 18:11:46 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 4650 invoked by uid 89); 20 Jun 2013 18:11:45 -0000 X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,TW_YG autolearn=ham version=3.3.1 Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 20 Jun 2013 18:10:59 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id D8F1D520781; Thu, 20 Jun 2013 20:10:56 +0200 (CEST) Date: Thu, 20 Jun 2013 18:44:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: cygport limitations (was: Adding MSYS functionality to Cygwin) Message-ID: <20130620181056.GA16923@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <51C0B08E.8080900@etr-usa.com> <51C0D956.4090905@etr-usa.com> <51C1B299.1000701@cwilson.fastmail.fm> <51C1F0F9.70601@etr-usa.com> <51C1FA8E.3000307@users.sourceforge.net> <51C33F38.4080103@etr-usa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <51C33F38.4080103@etr-usa.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-06/txt/msg00535.txt.bz2 On Jun 20 11:43, Warren Young wrote: > On 6/19/2013 12:38, Yaakov (Cygwin/X) wrote: > >On 2013-06-19 12:57, Warren Young wrote: > >>You're not talking about anything different than the sort of thing > >>Cygwin package maintainers go through, sometimes needing to arm-twist > >>odd build systems to behave according to cygport's expectations? > > > >I think you mean Cygwin's expectations? > > Not really, no. > [...] > My point is, cygport's default assumptions about how software gets > built and installed aren't always correct. Sometimes it has enough > flexibility to cope with those differences (e.g. my doxygen case) > and other times it's just not worth the bother (e.g. my ctags case). My point is, it's always worth to switch packages to cygport: - cygport is the closest we have to a unified build system (like rpm). If every maintainer would use cygport, it would allow us to change the build method to one along the lines of most Linux distros. In Linux distros, the maintainer provides only the spec file and the source archive. The actual build for all supported platforms could be done on a machine which creates the distro from there. - Cygport does cope with most problems you can come up with and if it doesn't, you can tweak it. Your ctags problem could have been easily solved by the lndirs method, for instance. And if cygport still doesn't cope, there's an active maintainer and a cygwin-apps mailing list for questions. - Cygport is pretty easy to use and other people can easily pick up your package and build another version using your Cygwin build settings, or even take over maintainership should the need arise. Of course, the better is the foe of the good, but unless somebody comes up with another build system which integrates nicely into Cygwin and is easier to use than cygport, cygport is the best system we have and I advocate for using it throughout. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple