DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=rpoMQ7Vyq0kfB1/ji5owon++kCkSe16qiCwDR7QCJRRlhbzWh82/d
	hxHRhkVIA2CGl73tQYYPM7h0BPrsGUZGcUbs+Wr+bY5W0U7F/zjB5fVV2oYOrEdJ
	Oz5h/aVf4nLmA/3I/owNLeRPSai/JCTxxa8Agrzqc3Pem3RW+XO84M=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Thu, 20 Jun 2013 20:10:56 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
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: <CABEPuQJDLjtbcLig1isTUJgb6RBCD8LNShbm9mTPcb9WM5S5fw@mail.gmail.com> <51C0B08E.8080900@etr-usa.com> <CABEPuQJJpRfPKSwZ7M0eTOdp1HxDcmvuy1=qXFHBw-8kLkZ1ZQ@mail.gmail.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)

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