X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
Message-ID:	<4811437C.6090405@cwilson.fastmail.fm>
Date:	Thu, 24 Apr 2008 22:35:40 -0400
From:	Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: [ANNOUNCEMENT] Updated: inetutils-1.5-3
References:	<announce DOT 48113324 DOT 7040007 AT cwilson DOT fastmail DOT fm> <48113B20 DOT 4060305 AT users DOT sourceforge DOT net>
In-Reply-To:	<48113B20.4060305@users.sourceforge.net>
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

Yaakov (Cygwin Ports) wrote:
> cygwin AT cwilson DOT fastmail DOT fm wrote:
> | Building this package requires a patched cygport:
> |   http://cygwin.com/ml/cygwin-apps/2008-03/msg00139.html
> 
> Are you sure?  AFAICS the attached WFM; I just need to update cygport in
> the distro.

Yep, looks like that will work -- once 0.3.9 is out. However, the 
inetutils-1.5-3 cygport file *as released* requires a function in 
neither the official cygport-0.3.8 nor the upcoming cygport-0.3.9. So, 
*as released*, inetutils-1.5-3 needs a patched cygport.

inetutils-1.5-4 won't.

 From an earlier thread:
> You could create dangling symlinks, knowing that .cygwin.patch will
 > eventually "undangle" them, but you can't do that before the ${S}
 > directory is created/mirrored from ${origsrcdir} -- if you did, then
 > the (dangling) symlinks created in ${origsrcdir} will be copied over
 > to the ${S} as-is: with the incorrect relative path to
 > CYGWIN-PATCHES/real-header-file. And deliberately creating dangling
 > symlinks is just plain icky.

The problem I was trying to "solve" was that the relative path to the 
actual file was different depending on which directory you were in -- 
${S} or ${origsrcdir}/${SRC_DIR}

Mine ${origsrcdir}/${SRC_DIR}:
(cd headers/arpa && ln -s ../../../../src/${SRC_DIR}/CYGWIN-PATCHES
/arpa/tftp.h .)
This path, if mirrored to ${S}, would be wrong.

Mine ${S}:
(cd headers/arpa      && ln -s ../../CYGWIN-PATCHES/arpa/tftp.h .)

so both symlinks end up pointing directly to 
${top}/src/${SRC_DIR}/CYGWIN-PATCHES/arpa/tftp.h
using relative paths from their respective locations.

We can't do even the first part of the above before mirroring -- which 
means that src_unpack_hook is too early (as is src_patch_hook).


Of course, if you use the absolute path to the target, you avoid all 
that. <smack/>

Yours (origsrcdir):
(cd headers/arpa      && ln -s ${C}/arpa/tftp.h .)

Yeah. Like that. Still, dangling symlinks are ugly. But your solution 
with (temporarily) dangling symlinks and src_unpack_hook() is much less 
ugly that my "be sure to duplicate all actions in both src dirs".

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -