----- Original Message ----- From: "Christopher Faylor" <[EMAIL PROTECTED]>
> On Sun, Nov 11, 2001 at 03:44:57PM +1100, Robert Collins wrote: > >----- Original Message ----- > >From: "Christopher Faylor" <[EMAIL PROTECTED]> > > > >> 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
