delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2001/07/26/21:46:09

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3B60C7B2.220A8A5B@ece.gatech.edu>
Date: Thu, 26 Jul 2001 21:45:22 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dario Alcocer <alcocer AT helixdigital DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: RPM installer (was Re: SETUP WIZARD FOR CYGWIN?XFREE86)
References: <17B78BDF120BD411B70100500422FC6309E2FD AT IIS000>
<15199 DOT 13618 DOT 671411 DOT 755243 AT coyote DOT priv DOT helixdigital DOT com>
<996103548 DOT 18053 DOT 7 DOT camel AT lifelesswks>
<3B5F5731 DOT 1090000 AT ece DOT gatech DOT edu> <15200 DOT 14597 DOT 953781 DOT 596499 AT coyote DOT priv DOT helixdigital DOT com>

Dario Alcocer wrote:

>     Chuck> The difficulty here is you've got to maintain TWO separate
>     Chuck> binaries for your core utilities -- one set of (cygwin
>     Chuck> itself, ash, rpm, db, etc) for the "real" system and one
>     Chuck> set for the "mini" environment.
> 
> I think this would be the major sticking point; having a parallel
> set of Cygwin binaries would be problematic, both for maintenance and
> support.
> 
> I think the approach I've outlined in the following message should
> work:
> 
>     http://www.cygwin.com/ml/cygwin/2001-07/msg01508.html

Ummm...in that message you DO talk about an "'installer-toolbox' version
of RPM".  I just like making things explicit: remember that executables
embed the filename of the DLLs on which they depend. 

So, if your "ITK" cygwin dll was named cygwin1.dll, then sure: you could
use the same rpm.exe both in the ITK and "for real".  But then, you're
deliberately installing two different cygwin1.dll's on a system (even
temporarily -- but what about people who like to keep the ITK around?). 
AND you have to play games with $PATH so that the "right" one is used in
the proper circumstances.  Sure, in THIS case the two dll's will not
cause the problems we've all grown to know and love, since they have
different shared region names.

But how do you explain that to your users?  "But I asked on the cygwin
list and they said never have two cgywin1.dll's.  So I deleted the one
with the newer timestamp from C:\cygwin\bin and left the one in
<desktop>\cygwin-itk\"

Geez. What a nightmare.

It seems easier (from a long-term, customer-support perspective) to
build the the ITK-cygwin dll with a different name (say,
cygwin1-itk.dll) and then link special versions of your ITK progs
against it.  So, you'd have:

cygwin1-itk
rpm-itk
ash-itk
textutils-itk
tcl/tk-itk

And that's probably it.  (Now that I think about it, you probably don't
need a special gcc for building the itk tools -- just swap two different
spec files...) Sure, short term this looks like hell.  But "The Right
Way To Do Things(tm)" usually does.  And is usually better in the long
run.  

--Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019