Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Brian Dessent wrote: So why can't the registry entry be path-to-dll instead of the fixed 'setup\rootdir' in order that the setup application could populate a drop-down list of all currently installed Cygwins? It could. Excellent. I second your suggestion. :-) But I think Chuck made a good point that the ability to have multiple installed copies extends to what you might call expert users, i.e. they must know the ins and outs of not actually ever using these two installs at once. And so we need to be careful not to give the impression that this is supposed to work in the general case. Sigh. Yes I read Chuck's clear denouncement that there is any whisper of there being a goal to support multiple Cygwin DLL's running simultaneously. However, that doesn't stop me from lobbying for setting up such a goal, and having a path-to-dll registry entry for the Cygwin DLL would be a step towards it, even if in the short term there was only one such path allowed in the registry, i.e., subsequent Cygwin setups would remove the previous path and replace it with the current user's choice, if it was different. Peter Klavins
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Brian Dessent wrote: Corinna Vinschen wrote: I don't know either. I'm not going to change what's in Cygwin right now since it's seldomly used anyway. So, for now, let's just agree on \Software\Cygwin\setup\rootdir so I can patch utils/path.cc and upload a new cygwin 1.7.0-4, ok? Does the Cygwin DLL know its own path? If so, how about \Software\Cygwin\path-to-dll ... to allow multiple parallel Cygwin installs? Peter Klavins
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Brian Dessent wrote: P?teris K?avi?š wrote: Does the Cygwin DLL know its own path? If so, how about \Software\Cygwin\path-to-dll ... to allow multiple parallel Cygwin installs? I think you've missed the context of this discussion. This key will never be read or written by the DLL, and the DLL already supports parallel installs by the fact that it uses /etc/fstab. Hmm. Well, if it's only setup that needs the registry entry, and if multiple setups, regardless of path-to-setup, are using the same fixed registry entry serially, what's the point of the registry entry? Remembering where the last setup's root was? Which could have been moved by the user afterwards? Peter Klavins
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Brian Dessent wrote: P?teris K?avi?š wrote: So that when you run setup it can start out with the same root that you last used so that you don't have to type it in every time. That, and also so that the native tools like cygcheck can locate the root dir. So why can't the registry entry be path-to-dll instead of the fixed 'setup\rootdir' in order that the setup application could populate a drop-down list of all currently installed Cygwins? This will be a minor problem in that if you had two installs, both cygchecks will think the root is the last one that you updated with setup. Corinna, perhaps cygcheck needs to compute the root relative to its location like the DLL instead. This means cygcheck will always have to be in /bin, but I think that's fine; it's not like it has ever been anywhere else. Maybe all cyg*.exe native Windows applications could use this same algorithm to compute their root. Manually moving an installed cygwin tree would be a silly thing to do, it would break all your services for example. Would this problem go away if cygrunsrv.exe used the same algorithm to compute its root? Anyway, if someone were silly enough to do that they would just need to enter the new location in setup; but this will be the case whether or not setup remembers its last install root, so I don't see how this is pertinent. I have (finally) started using an environment where I share all my personal files on a separate disk drive accessible from all my bootable operating systems, whether it's Vista, WS2008, or Debian. The drive names (and mount points) vary. It's the same as moving install trees, and it would be nice if Cygwin didn't really care that when I started the services this time they were started from a different location than last time. [In any case, Brian, I appreciate your time in answering my off-beat questions and realise that they aren't 'core' to the business of getting Cygwin to work. Sooner or later I'll put together the correct build environment, something which has eluded me as yet, to produce some diff's of ideas I have, rather than just talk about them.] Peter Klavins
