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=rSLerg5zfGV6Bg/5IItjUx2fRx741Q2LVEmHIrKKQTc
	PDRSfvM7+qQLoOfoVN/Zif3HV2NTNM7j5UhYZRJIKXNSJsNCiZoxXtP1qVKC99CB
	ghuJZLMq3X8hvUnu20uPDaMvSqD5Ftxia0sSIAhEefRfNl3r+76HNVAvgR4oAdcY
	=
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=eBTuU6nfR/9yLTjvkvhMQZ4KH5g=; b=hHgLxhcOCopktL9d+
	VByVRH9kM1qdhV24bMZjed4rl6VN2FOjhwbCuUVKSC5ru1bAU/w9erns9/gzvJZd
	5H4z3iLlxAtKwdmn4zofyv6mVoaOOGKY/T4SPIXFJnCnGQ+BFlQKVFQUhbfFAC5H
	KMV+bGXEBmVidi+aZJ4ZqFXaQ8=
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=-3.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS,TW_YG autolearn=ham version=3.3.1
X-Received:	by 10.67.1.106 with SMTP id bf10mr3187746pad.162.1371753849333; Thu, 20 Jun 2013 11:44:09 -0700 (PDT)
Message-ID:	<51C34D7C.3080703@users.sourceforge.net>
Date:	Thu, 20 Jun 2013 13:44:12 -0500
From:	"Yaakov (Cygwin/X)" <yselkowitz AT users DOT sourceforge DOT net>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: cygport limitations
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> <51C33F38 DOT 4080103 AT etr-usa DOT com>
In-Reply-To:	<51C33F38.4080103@etr-usa.com>

On 2013-06-20 12:43, Warren Young wrote:
> 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.

This is explained in the manual wrt cygconf:

> * cygconf is intended for configure scripts generated by, or compatible
>   with, autoconf. Packages with handwritten configure scripts may not
>   accept allthe flags used by cygconf, in which case a direct call to
>   the configure  script is in order.

In this case, not having looked at ctags, you'll probably need something 
along the lines of:

src_compile() {
     lndirs
     cd ${B}
     ./configure --prefix=/usr || error "configure failed"
     cygmake
}

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

FWIW, CYGCONF_ARGS has been around for a *long* time.

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

There's nothing wrong with that.  src_compile(), src_test(), and 
src_install() are intended to be provided by cygport(5)s; the provided 
*defaults* of those are NOT opaque APIs (hence they are actually shown 
in the docs) and are meant to be overridden whenever necessary.

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

There should NEVER be a reason that you can't use cygport for your 
packages.  If you're having an issue, just provide your (draft) 
cygport(5) and ask.


Yaakov


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