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=oTyG2eZ3KICpthzbMfTCeTcfS1QgZ4v1cpyi8J43EMj Vef6+GH8qhnuuDRF5qj9Ejt+ZO+bj70UZWevDV80YhiW/pj3/C+VptD+x85nM6xO xq4UDEHwF3LhMdVYNRdbpWdH4msNdL72JbdPGDtdD4rPFlE4MdTPehTNclyYeBsM = 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=EWXGn1FolPhZYoDrd15q7cbaF2o=; b=suxyxgHAVe0ggVENM r/Ut7HlQLSj2IWW2H930QwcYV12YloM3QKih4bKN3GoK0aLlUJByFvhO2l6lgVEK KSkVfRW/+PO9wFsk1yADfeS0TCwdYQCGeU1LxKB97MdQCInvMWYF+WzI+QELDoaR 0TcIq+BSKzYkx3PXuVVlCDkn0M= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_HELO_PASS autolearn=ham version=3.3.2 Message-ID: <520BE69B.6050900@towo.net> Date: Wed, 14 Aug 2013 22:20:43 +0200 From: Thomas Wolff 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> X-TagToolbar-Keys: D20130814222043203 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