Re: mingw path/mount handling code (Was: Re: Practical method for automatic Cygwin install?)
On Dec 9 07:48, Brian Dessent wrote: The way I see it, in a perfect world, this library would be BSD/MIT licensed, or at the very least LGPL, so that foreign programs by 3PPs could use it unencumbered, so that they can function better with Cygwin. However, winsup/utils/path.cc is under the Cygwin license. I don't suppose there is any chance of getting Redhet to relicense parts of the utils directory? It's in the loop, sort of. I'm working on getting the utils directory relicensed for about 18 months now. Progress is somewhat slow, though... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- 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/
mingw path/mount handling code (Was: Re: Practical method for automatic Cygwin install?)
Christopher Faylor wrote: FWIW, this idea of creating a mingw libcygpath really appeals to me and it's been an idea I've been meaning to look at for a while. It would be a library that knows how to read the mount table, and do basic path conversions, without depending on cygwin1.dll. Then cygpath and setup.exe could both statically link to this library, and it would be available to other users as well. FWIW, Robert Collins and I talked about doing this years ago but it just suffered due to SHTDI. I think that path.cc in the utils directory should be a pretty good start towards a library for reading the mount table. It is what is used by strace.cc and cygcheck.cc. I've been thinking about this a little more. The way I see it, in a perfect world, this library would be BSD/MIT licensed, or at the very least LGPL, so that foreign programs by 3PPs could use it unencumbered, so that they can function better with Cygwin. However, winsup/utils/path.cc is under the Cygwin license. I don't suppose there is any chance of getting Redhet to relicense parts of the utils directory? It seems small enough that it could be reimplemented without a lot of hassle, but it's still extra work. Has this topic already been discussed, or do I need to do more due diligence on this idea? I am considering putting some time into this but I think GPL is not the right way to go. Would the approximate path be a) create, test, and debug this free-standing libcygpath (libcygmount?), b) submit patches to cygpath and setup to use this library? Brian -- 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/
Re: mingw path/mount handling code (Was: Re: Practical method for automatic Cygwin install?)
On Fri, Dec 09, 2005 at 07:48:24AM -0800, Brian Dessent wrote: Christopher Faylor wrote: FWIW, this idea of creating a mingw libcygpath really appeals to me and it's been an idea I've been meaning to look at for a while. It would be a library that knows how to read the mount table, and do basic path conversions, without depending on cygwin1.dll. Then cygpath and setup.exe could both statically link to this library, and it would be available to other users as well. FWIW, Robert Collins and I talked about doing this years ago but it just suffered due to SHTDI. I think that path.cc in the utils directory should be a pretty good start towards a library for reading the mount table. It is what is used by strace.cc and cygcheck.cc. I've been thinking about this a little more. The way I see it, in a perfect world, this library would be BSD/MIT licensed, or at the very least LGPL, so that foreign programs by 3PPs could use it unencumbered, so that they can function better with Cygwin. However, winsup/utils/path.cc is under the Cygwin license. I don't suppose there is any chance of getting Redhet to relicense parts of the utils directory? It seems small enough that it could be reimplemented without a lot of hassle, but it's still extra work. I think there is very small chance of that. IIRC, some of that code is straight out of the cygwin DLL itself. I think that anyone who had studied the cygwin path handling code would have a tough time proving that there was no taintedness if they tried to produce a library under a different license. cgf -- 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/
Re: mingw path/mount handling code (Was: Re: Practical method for automatic Cygwin install?)
Christopher Faylor wrote: I think there is very small chance of that. IIRC, some of that code is straight out of the cygwin DLL itself. I think that anyone who had studied the cygwin path handling code would have a tough time proving that there was no taintedness if they tried to produce a library under a different license. Crud. Well I suppose from a code reuse standpoint it would still make sense to factor out that stuff so that setup and cygcheck (and anything else GPL) can share it. But without a relicensed version it still means that 3PPs that want to gracefully distribute Cygwin stuff have to write all the mount table stuff themselves (or run /bin/mount, which I guess is the mantra anyway.) Brian -- 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/
Re: mingw path/mount handling code (Was: Re: Practical method for automatic Cygwin install?)
On Fri, Dec 09, 2005 at 08:29:06AM -0800, Brian Dessent wrote: Christopher Faylor wrote: I think there is very small chance of that. IIRC, some of that code is straight out of the cygwin DLL itself. I think that anyone who had studied the cygwin path handling code would have a tough time proving that there was no taintedness if they tried to produce a library under a different license. Crud. Well I suppose from a code reuse standpoint it would still make sense to factor out that stuff so that setup and cygcheck (and anything else GPL) can share it. Remember that cygcheck and strace are already sharing the code in path.cc. It's not clear to me what more needs to be done except possibly handle symlinks. But without a relicensed version it still means that 3PPs that want to gracefully distribute Cygwin stuff have to write all the mount table stuff themselves (or run /bin/mount, which I guess is the mantra anyway.) ...or run cygpath. FWIW, the basic problem with Red Hat these days is getting them to pay any attention to cygwin at all. The corporate VP in legal who used to be at least somewhat responsive to my cygwin queries has moved on to other concerns within the company and, from what I've heard, no one else seems inclined to answer questions. You know that cygwin runs on Windoze (or is it Window$?) after all. So, even if there was a chance that someone in Red Hat could make the recommendation to release the path.cc source code under a looser license, it is extremely unlikely that you could get an official corporate response on the matter. What fun. cgf -- 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/
Re: Practical method for automatic Cygwin install?
On Tue, Nov 22, 2005 at 09:51:56PM -0600, William J. Leslie wrote: Note: I am rephrasing the question I asked last time (for which the conversation drifted into GPL and licensing issues). My program depends on cygwin DLLs, my installer must make sure these dependencies are satisfied. I've heard that installing private copies of cygwin DLLs can lead to version mismatches. Instead of installing private copies of the cygwin DLLs, my installer will install a complete (but minimal) cygwin installation to c:\cygwin. There are a few issues that I am not sure how to deal with: 1) How to determine whether or not cygwin is already installed? If so, what is the prefix path (e.g. c:\cygwin)? Right now, the only way to do it is to query the registry. I think I'm convinced that cygwin will always need to add something to the registry so the concept of querying the registry to find out if cygwin is installed should be useful for the foreseeable future, even if the location to query might change (and what a hue and cry there will be if it does change). It is possible to copy the cygwin DLL to a system and just have it work, though, so what I would do is: 0) Look at the current installer to see how it does things. 1) Try running mount --version to see if it is the cygwin version. If it succeeds and the word cygwin shows up in the output, then cygwin is installed. This assumes that mount is in the path. 2) Look in the registry (in the currently used location) for the cygwin root directory. See if the bin directory under this location contains cygwin1.dll. If it succeeds, then cygwin is installed. 2) If cygwin is already installed, what optional packages are present? What versions? Use the same method as the current setup (and cygcheck) to determine what packages are installed. 3) If cygwin is NOT installed, how do we install it, without setup.exe prompts? (I have a gut feeling that it's a bit more complicated than just untarring packages.) It's not a lot more complicated than that. You have to get dependencies right and you have to deal with post install scripts. 4) If cygwin is installed, but some optional packages need version upgrades, how do we accomplish that? As Gary said in another message, it sounds like the best way to accomplish what you want is to augment setup.exe and make sure that your changes show up in the official version. You contribute to setup.exe via the cygwin-apps mailing list. Maybe you might want to peruse the archives of that mailing list to see how that happens. cgf -- 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/
Re: Practical method for automatic Cygwin install?
On Wed, 23 Nov 2005, Christopher Faylor wrote: On Tue, Nov 22, 2005 at 09:51:56PM -0600, William J. Leslie wrote: Note: I am rephrasing the question I asked last time (for which the conversation drifted into GPL and licensing issues). My program depends on cygwin DLLs, my installer must make sure these dependencies are satisfied. I've heard that installing private copies of cygwin DLLs can lead to version mismatches. Instead of installing private copies of the cygwin DLLs, my installer will install a complete (but minimal) cygwin installation to c:\cygwin. There are a few issues that I am not sure how to deal with: 1) How to determine whether or not cygwin is already installed? If so, what is the prefix path (e.g. c:\cygwin)? Right now, the only way to do it is to query the registry. I think I'm convinced that cygwin will always need to add something to the registry so the concept of querying the registry to find out if cygwin is installed should be useful for the foreseeable future, even if the location to query might change (and what a hue and cry there will be if it does change). It is possible to copy the cygwin DLL to a system and just have it work, though, so what I would do is: 0) Look at the current installer to see how it does things. 1) Try running mount --version to see if it is the cygwin version. If it succeeds and the word cygwin shows up in the output, then cygwin is installed. This assumes that mount is in the path. 2) Look in the registry (in the currently used location) for the cygwin root directory. See if the bin directory under this location contains cygwin1.dll. If it succeeds, then cygwin is installed. Or you could look at how setup.exe/cygcheck does it and help extract the mount code into a library that could be linked into other apps. 2) If cygwin is already installed, what optional packages are present? What versions? Use the same method as the current setup (and cygcheck) to determine what packages are installed. 3) If cygwin is NOT installed, how do we install it, without setup.exe prompts? (I have a gut feeling that it's a bit more complicated than just untarring packages.) It's not a lot more complicated than that. You have to get dependencies right and you have to deal with post install scripts. And you have to make sure that whatever non-Cygwin application/library you use to untar packages understands and can create Cygwin symlinks and hard links (optional, copies would work just as well). 4) If cygwin is installed, but some optional packages need version upgrades, how do we accomplish that? As Gary said in another message, it sounds like the best way to accomplish what you want is to augment setup.exe and make sure that your changes show up in the official version. You contribute to setup.exe via the cygwin-apps mailing list. Maybe you might want to peruse the archives of that mailing list to see how that happens. Another thing that I don't recall mentioned in this thread is that setup.exe has an unattended mode (which is not scriptable, but that could be alleviated with custom setup.ini files). The GUI will still pop up, but user interaction isn't really necessary. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. /DA -- 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/
Re: Practical method for automatic Cygwin install?
Igor Pechtchanski wrote: Or you could look at how setup.exe/cygcheck does it and help extract the mount code into a library that could be linked into other apps. FWIW, this idea of creating a mingw libcygpath really appeals to me and it's been an idea I've been meaning to look at for a while. It would be a library that knows how to read the mount table, and do basic path conversions, without depending on cygwin1.dll. Then cygpath and setup.exe could both statically link to this library, and it would be available to other users as well. Brian -- 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/
Re: Practical method for automatic Cygwin install?
On Wed, Nov 23, 2005 at 01:30:37PM -0800, Brian Dessent wrote: Igor Pechtchanski wrote: Or you could look at how setup.exe/cygcheck does it and help extract the mount code into a library that could be linked into other apps. FWIW, this idea of creating a mingw libcygpath really appeals to me and it's been an idea I've been meaning to look at for a while. It would be a library that knows how to read the mount table, and do basic path conversions, without depending on cygwin1.dll. Then cygpath and setup.exe could both statically link to this library, and it would be available to other users as well. FWIW, Robert Collins and I talked about doing this years ago but it just suffered due to SHTDI. I think that path.cc in the utils directory should be a pretty good start towards a library for reading the mount table. It is what is used by strace.cc and cygcheck.cc. cgf -- 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/
RE: Practical method for automatic Cygwin install?
From: William J. Leslie Sent: Tuesday, November 22, 2005 9:52 PM Subject: Practical method for automatic Cygwin install? = = = = = = = = = Note: I am rephrasing the question I asked last time (for which the conversation drifted into GPL and licensing issues). My program depends on cygwin DLLs, my installer must make sure these dependencies are satisfied. I've heard that installing private copies of cygwin DLLs can lead to version mismatches. Instead of installing private copies of the cygwin DLLs, my installer will install a complete (but minimal) cygwin installation to c:\cygwin. There are a few issues that I am not sure how to deal with: 1) How to determine whether or not cygwin is already installed? If so, what is the prefix path (e.g. c:\cygwin)? There's currently not a great way to do that. Somebody just asked the same question(s), see that thread. 2) If cygwin is already installed, what optional packages are present? What versions? If I read another thread right, there may or may not be a way to do this in the near future, assuming you've got #1. 3) If cygwin is NOT installed, how do we install it, without setup.exe prompts? (I have a gut feeling that it's a bit more complicated than just untarring packages.) I believe this can now be done with sufficiently-doctored setup.ini files. I've never tried it myself. 4) If cygwin is installed, but some optional packages need version upgrades, how do we accomplish that? Via the normal means, i.e. the Cygwin setup utility. Probably any developer who has tried to release software for the cygwin environment has thought about this. Users demand absolute automation of the installer; I can't tell them to do stuff like: This package requires cygwin. Please go install Cygwin from www.cygwin.com, and click Retry when you're finished. When all is said and done, I rather suspect you're going to have to. Nope, that would not be acceptable; it MUST be automatic! But apparently Cygwin's setup utility cannot be automated, only GUI-based. Surely there are ways for installers like mine to install cygwin without having to worry about the messy details. Or maybe not. Does anyone know? I do. There's no software that's ever been written that didn't have to worry about the messy details, and installing Cygwin and a bunch of utilities in a manner which is not officially supported is probably at the top of that list. It sounds to me that what you really should do is release your software as a Cygwin package, and then work on adding the functionality you need to Cygwin's setup.exe. Thank You Will -- Gary R. Van Sickle -- 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/
