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=oTyG2eZ3KICpthzbMfTCeTcfS1QgZ4v1cpyi8J43EMj
	Vef6+GH8qhnuuDRF5qj9Ejt+ZO+bj70UZWevDV80YhiW/pj3/C+VptD+x85nM6xO
	xq4UDEHwF3LhMdVYNRdbpWdH4msNdL72JbdPGDtdD4rPFlE4MdTPehTNclyYeBsM
	=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <520BE69B.6050900@towo.net>
Date: Wed, 14 Aug 2013 22:20:43 +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: Re: hassles with cygport
References: <5207C654 DOT 2020401 AT towo DOT net> <5207CF18 DOT 1050104 AT gmail DOT com> <20130812103730 DOT GC2691 AT calimero DOT vinschen DOT de>
In-Reply-To: <20130812103730.GC2691@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


 > > >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
 > > >
 > > >...
 >
 > I really don't understand your problem here.  If a patch doesn't apply
 > to the original package, in how far is that cygport's fault?
The patch problem is not cygport's fault. My point was that cygport "prep"
combines the unpacking and the patching which is then bound to fail the
first time without a chance to check first. An optional split into
"unpack" and "patch" might be useful.
 > ...
 > The package's build problems are expected to be already solved.
Sure, but applying cygwin-specific patches are not the upstream build.


 > > >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?
 >
 > DESTDIR is the default variable used in many projects to define
 > an installation directory.  This is pretty common, really. E.g.
 >
 >   configure --prefix=/usr; make; make install DESTDIR=/tmp
 >
 > will configure the project to install into /usr, but the final
 > `make install DESTDIR=...' will install the files under /tmp/usr
 > for packaging.
Yes, I know this. I wasn't sure though whether cygport would expect a 
certain
directory to be used for packaging, or whether I should choose one
and how cygport "package" would be instructed to package from the same
(the manual does not mention DESTDIR or $D under Packaging).

Actually, I had pondered this because the upstream package (algol68g) 
installs
into /usr/local by default, and DESTDIR did not seem to work manually 
with it.
Later, after giving it a try just dropping all DESTDIR attempts, I
was surprised that cygport was miraculously able to fix the installation
target automagically. Convenient but mysterious...


 > Cygport's default installation routine is called cyginstall. That's
 > what is called by default if you don't specify your own src_install()
 > function.  The default behaviour of cyginstall is to call the pretty
 > common
 >
 >   make install DESTDIR=[your-project-dir/inst]
This reads a little bit more cryptic in the cyport manual...
Proposal:
Maybe a pattern cygport file would be useful that includes all these
src_ etc functions and their contents such that it produces exactly the
default behaviour without the functions. That might give a better clue on
where to start for individual adaptations.


 > Did you look into the cygport files of other projects?
 > That may be a good help.
Yes, a few, and they looked all so different that I didn't find it very
helpful; maybe I chose the wrong ones to start with.
 > There are many hundreds of them in all kinds of
 > complexities from dead easy to almost too much to handle.
I think my problem was that I had no idea whether my upstream project
is one of the "dead easy" kind for cygport - from the "hassles" I was
facing I had first assumed the other end of the scale.


About the error message "which: no autopoint in ($PATH)"
(which I had reported before, 
http://cygwin.com/ml/cygwin-apps/2012-04/msg00030.html)
"cygcheck -p autopoint" reveals "gettext",
so is a gettext dependency missing in cygport's setup.hint?


(Some further questions, related to actual packages, will go to 
cygwin-apps.)
------
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