At 02:10 PM 12/9/2003, David A. Cobb you wrote: >I recently tried out a couple of software packages -- SSH_CONFIGURATOR is one that >sticks in my mind -- that are built with Cygwin. Their README documents said there >wouldn't be a problem with a "properly installed" existing Cygwin. Well, there was a >problem with >mine, which otherwise works just fine for me. Possibly they looked for cygwin1.dll in >a specific place, possibly they tried to use PATH. I don't know. Anyway, they left >me with multiple cygwin1.dll's so nothing worked at all until I tore them out by the >roots. >OK, that may be the packagers problem, not ours. However, I'm wondering if we could >make it easier? How about storing /HKLM/Cygnus >Solutions/Cygwin/DLL_PATH="native:/path/to/cygwin1.dll and > /HKLM/Cygnus Solutions/Cygwin/DLL_VERSION="1.2.3" > >And providing a simple C routine to return the critical information. >I'm less sure about this piece -- most use things like InstallShield and I don't know >how the scripting works there. Of course, if they simply looked at the mount point >/HKLM/Cyg.../Cygwin/mounts_v2/bin, they could work it all out!!!
The prescribed approach is for third parties to not bundle cygwin1.dll but instead point to cygwin.com and say "Install This First". An alternative is a nice automated way in their installer to invoke the Cygwin installer. If they do this, then there's no chance of having more than 1 cygwin1.dll installed and no one needs to check for one. Of course, doing the checking is not hard (FindFirstFile()/FindNextFile()) even if it's not necessary. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
