Mail Archives: cygwin-apps/2001/11/11/05:26:50
----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
> On Sun, Nov 11, 2001 at 03:44:57PM +1100, Robert Collins wrote:
> >----- Original Message -----
> >From: "Christopher Faylor" <cgf AT redhat DOT com>
> >
> >> I don't anticipate that they will ever go away, so I think we
should
> >stick
> >> with having setup.exe create the "old style" method. It will keep
the
> >> code size down in setup.exe.
> >
> >Actually it won't - we already create .lnk files for the start menu.
(It
> >was aiming to reduce that overhead that caused my question.
>
> AFAIK, it isn't creating cygwin links. It's creating Windows lnk
files,
> isn't it?
I had a look at Corinnna's .lnk code in cygwin, and they "ain't that
different".
> >>Or, maybe this will become a non-issue when/if setup.exe is split in
> >>two since we'll be able to use cygwin tar at that point. >
> >
> >Not really, because the inital bootstrap may well have shortcuts in
it.
>
> If you say so. I don't see why it would. That would seem to be
counter
> to the reason for splitting up setup.exe. I thought that you'd want
> to have all of the cygwin intelligence in the second half.
Some examples I'd be hesitant to put statically into setup.exe
IPC/FIFO's/mmaps.
Running a setup equivalent from the command line in a console.
Linking to a db library dynamically.
However, setup.exe, even a minimal bootstrapping version, cannot
guarantee that no boot strap package will have sym or hardlinks. Take
cygwin for instance - libc.a is a link to libcygwin.a. That package is a
requirement to bootstrap :].
> So, I guess I don't have an opinion on this. I should point out that
> the "new" links will actually work better on remote shares so maybe
> that's enough of an argument for them.
>
> I'd like to get Corinna's opinion on this, though.
Absolutely. I'm really impartial on this change.
Rob
- Raw text -