Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <0d0f01c17597$e3fbb540$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: <cygwin-apps AT sources DOT redhat DOT com>
References: <093e01c1745c$aece3f50$0200a8c0 AT lifelesswks> <3C00AF34 DOT 7070707 AT ece DOT gatech DOT edu>
Subject: Re: recoverable downloads - opinions sought
Date: Sun, 25 Nov 2001 20:59:34 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 25 Nov 2001 09:59:23.0611 (UTC) FILETIME=[DC174AB0:01C17597]

----- Original Message -----
From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>


> Robert Collins wrote:
> But if setup used an external library (or program) it would have to be
a
> non-cygwin version, right?

Not necessarily. Cygwin1.dll can be loaded dynamically.

> > Using an external helper, via a bootstrap process will be a lot
easier,
> > but will sacrifice the functionality when on a non-cygwin machine.
>
> You're assuming that the external helper is a cygwin program, I guess.

Yes.

> Ummm...I'm reminded of Dario's rpm-based cygwin distribution.  He had
a
> bootstrap phase that installed cygwin(dll, bare minumum tools, rpm
> itself), and then used rpm to install everything else...
>
> If we're going to go with a two phase setup, then his idea makes more
sense
> than continuing to roll our own. The big argument against his plan was
>
> (a) two phase is bad (b) why throw away our perfectly good setup tool.
Okay,
>
> that's two arguments. ;-)

I don't think two phase is bad, but supporting the download-only version
on non-cygwin machines is the cruncher. As for b) I'm very much in
favour of setup.exe being the user interface - to whatever does the
dirty work, be that setup.exe or another tool.

> > So I'm in favour of internal code/static library linkage. A dynamic
> > library _could_ be used, but we'd ned to treat it as a special case,
not
> > as a standard isntall-and-log package.
>
> Yep.  But if it's a special case, then we might as well link it in
> statically.  If it were in a DLL, we can't update it on-the-fly from
> setup because setup.exe is still using it...so updates of that DLL
have
> to be done manually.

Exactly. (About the special case -> link static logic). As for updating
the .dll that's not a problem. Here's why. The .dll will not be in
setup.exe's import table so setup.exe can check the dll's version as the
first thing it does.

> > The alternative to internal/static code is to go down the path of
> > splitting setup into two builds, but as we'd _still_ have to get the
> > download-without-cygwin part right, I see no benefit in this.
>
> Also,
> http://www.cygwin.com/ml/cygwin-apps/2001-07/msg00074.html
>
> I seem to remember that in early september Dario actually put together
> an ISO that embodied his whole rpm-based cygwin dist including a
> tk/tcl-based 'bootstrap' installer...

Which was really neat. I should get that out an review it :].

Rob