X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=I1w96YMFafq9qdCi1HX65LBGbbgAEKqOmwxHkts+JmE
	46/TSyeNowHaY+jnRvTWrmCkxqJbHnEOgiGCqT5Pq4+d/JCDZFwkHcQ8YOuDDsPO
	/vAfoFfe2zZdDEbyfQmUW1LckSLuvs0pXP4INjEf2kbh44NA0gwuywUgQXIv865E
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=jG+NznroMFWbHcOVNslr9ZeJPEo=; b=P+l4RywQlcUKBMeEJ
	8Vk4QZrIE/B2LEIfnGq8hdj6YWU7nxSNGAxaSJEvxuZg8/mD0ScnRG6HpLbiKL8+
	UqAbw22dJihxKZ4PtJ1MUqF4Uk2dpIFwJKd4uLlfTohlCLpF+wMZWsyjSraiWch7
	UG7aP58RZFbwuPE6z5fJhpK/QU=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status:	No, score=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD,TW_YG autolearn=ham version=3.3.1
Message-ID:	<51C33F38.4080103@etr-usa.com>
Date:	Thu, 20 Jun 2013 11:43:20 -0600
From:	Warren Young <warren AT etr-usa DOT com>
User-Agent:	Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version:	1.0
To:	Cygwin-L <cygwin AT cygwin DOT com>
Subject:	Re: cygport limitations (was: Adding MSYS functionality to Cygwin)
References:	<CABEPuQJDLjtbcLig1isTUJgb6RBCD8LNShbm9mTPcb9WM5S5fw AT mail DOT gmail DOT com> <51C0B08E DOT 8080900 AT etr-usa DOT com> <CABEPuQJJpRfPKSwZ7M0eTOdp1HxDcmvuy1=qXFHBw-8kLkZ1ZQ AT mail DOT gmail DOT com> <51C0D956 DOT 4090905 AT etr-usa DOT com> <51C1B299 DOT 1000701 AT cwilson DOT fastmail DOT fm> <51C1F0F9 DOT 70601 AT etr-usa DOT com> <51C1FA8E DOT 3000307 AT users DOT sourceforge DOT net>
In-Reply-To:	<51C1FA8E.3000307@users.sourceforge.net>

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.

I'm assuming everyone is using cygport now to create packages, or can't 
because of one of these violated expectations.

My ctags package is one of the latter, because although it ships with a 
configure script, it isn't an autoconf configure script.  When I tried 
migrating the package to cygport 3.5 years ago, cygport failed to DTRT 
because the ctags build system doesn't know how to configure and build 
outside the source tree.  I ended up falling back on my custom build 
script, which simply builds in-tree, then overrides some make(!) 
variables to force it to install into a temp directory, which I then 
pack up by hand.  This is tolerable because ctags is a relatively simple 
package.

I think I see how to get cygport to build this package now, but it 
wouldn't buy me much, because I'd be overriding so much of its default 
behavior.  All I'd be doing is pushing it into this next category.

That second category of packages are those that are built using cygport 
despite the fact that it requires a highly customized .cygport file. 
The more customizations you add, the more of cygport's base assumptions 
you are violating with your package.

The last doxygen package I shipped was a good example of this:

1. I had to pass "--platform linux-g++" to configure to get it to build 
correctly.  (It might have been one of those cases where it saw #if 
WINDOWS == true and did the wrong thing.)  I don't know if CYGCONF_ARGS 
didn't exist when I wrote that, but for some reason I felt compelled to 
override the src_compile rule to pass this flag.

2. Though I now know about CYGCONF_ARGS, if I picked the package back up 
for some reason, I don't think I could get rid of my src_compile() 
override because of a second build problem: Doxygen's own documentation 
has a primitive and completely separate build system.  Not only does 
"make" at the top level not "cd doc && make", but doc/Makefile also 
doesn't understand things like DESTDIR.  I ended up needing to override 
src_install(), too.

I don't mean to impugn cygport's capabilities, or yours, Yaakov.  I 
prefer to use cygport, and don't like it when I can't.

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).

--
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

- Raw text -