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
	:content-type:content-transfer-encoding; q=dns; s=default; b=JaR
	Cs0tdekS8THmpf+4xloeoPyfm+FXOD/0gjwvUPl4x/KbEoCddABNNdtKYrCSolOz
	NTvK3O3Y0xvnkbHE1fMKw+A6917P3GvmF4wmiYnKKxaHC0kOlbes+CI1h12VwaRY
	EhIUudDKG509+i9zHkuAGq+WSbSMtOMceIQMeeCg=
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
	:content-type:content-transfer-encoding; s=default; bh=HZVbAOugM
	VGyXQm+hPpXVTA1jEI=; b=gF5k9qpxtQWy57hHNR03JFkupDxzTnzs1m5Mbd+Rk
	yeMup6TMfBhqRT017nZV8Q6UdrAUPfQuMbHl3EF4+lkOG1efL3/URWBTrbQpLYxj
	eH40gnwJHaIugzpslxwaNQp0XKddjN4Ygx+AqBHfEunLTeAL8endMiCS2adUgD4M
	Xg=
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=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_HELO_PASS autolearn=ham version=3.3.2
Message-ID:	<5207C654.2020401@towo.net>
Date:	Sun, 11 Aug 2013 19:13:56 +0200
From:	Thomas Wolff <towo AT towo DOT net>
User-Agent:	Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	hassles with cygport
Note-from-DJ:	This may be spam

I tried to migrate a package to using cygport. As I had announced before,
I'm using this occasion to report some of the trouble I've experienced 
with it,
listing this case as a kind of "log" of my porting attempt (which 
finally failed).
While probably most of the single problems might appear to be small and
easily solvable, the mere amount of issues and peculiarities is what
makes cygport a rather cumbersome tool for me.


rename old cygport file to new version
⇒ why is this needed? couldn't it be version-agnostic?

edit cygport file to change version number of patch file, plus
rename patch file to new version
⇒ bothersome

with SRC_URI="http://.../${P}.tar.gz" trying
cygport ... almostall
⇒ *** ERROR: Cannot find source package ...

now archive already downloaded, so cygport [almost]all not desired
⇒ look up sequence of commands (prep, compile, install, package) I 
couldn't remember

cygport ... prep
⇒ likely, the patch fails, of course, because sources have changed,
so why is there not a step "unpack" after which I would check the patch?

trying to adapt patch
⇒ searching for patched files first, somewhere among a bunch of directories;
"origsrc" good guess, but tried "src" first anyway
⇒ bothersome

trying to remember correct tuning of diff to produce patch;
adapted patch
⇒ have to unpack again, with cygport ... prep
⇒ redundant, but well

need to add a parameter to the package configure script
⇒ trying to find out how to achieve this:
after some googling etc, running cygstart /usr/share/doc/cygport/manual.html
found WAF_CONFIGURE_FLAGS for "additional arguments to pass to 'waf 
configure'"
⇒ what is waf??? not likely to lead to success
found R_CONFIGURE_ARGS for "flag(s) to be passed to the configure script 
used by module packages containing native code"
⇒ sounds somewhat better, but what the waf are "module packages 
containing native code"?
⇒ thinking again, not likely to succeed
found src_compile, looks more likely to be useful
⇒ however, its description is somewhat "nested", so where would I insert
specific parameters or commands?
it basically appears to call cygmake (which is obviously an internal 
cygport thing),
also another cygport file lists:
src_compile() {
   lndirs
   cd ${B}
   cygmake
}
but cygmake is described "Calls 'make'", so where is configure invoked??
⇒ giving up, ignoring this detail for now

repeat cygport ... prep
cygport ... compile
getting message
which: no autopoint in ($PATH)
cygport hangs
⇒ giving up

running configure and make manually

trying to take up cygport sequence:
cygport ... install
getting message
make: *** Keine Regel, um »install« zu erstellen.  Schluss.
*** ERROR: make install DESTDIR failed
⇒ what is this? should I provide a DESTDIR? the manual says:
install into a DESTDIR, and run post-installation steps
this is quite unclear, what is "a DESTDIR"? something I need to provide
or cygport would pick?
if I provide it myself, how would the subsequent step "cygport ... package"
know which DESTDIR I used? I could provide it again, but this is not
mentioned in the manual
⇒ very obscure

attempt: mkdir inst; DESTDIR=inst cygport ... install
⇒ fails, same error

––––––
Thomas

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