This is the mail archive of the
mailing list for the Cygwin project.
Multiple Cygwins/ Distributing Cygwin apps
- From: John Moore <gmanenews at tinyvital dot com>
- To: cygwin at cygwin dot com
- Date: Sun, 02 Nov 2003 18:29:17 -0700
- Subject: Multiple Cygwins/ Distributing Cygwin apps
I have done a bunch of googling and I find this subject comes up
periodically. I have just spent many wasted hours because a vendor
shipped a tool I have to have (customer mandate), tightly integrated
with a cygwin that is old and has a buggy cvs. Meanwhile I am using
another cygwin for another customer... the latest version.
For me, the inability to install two cygwins that are independent has
already cost me a bunch of time. When I grumbled to a friend, his answer
was "buy another machine for that application."
This is a poor answer, but I may have to. Or I'll have to find what
magic has to be switched to instantiate one and hide the other...
something that is mentioned in some of the email I found, but no details
Cygwin is a great tool and it has this really neat installer so I can
keep it up to date. But when a vendor ships a binary, that vendor must
ship a binary Cygwin DLL, and there is no way it is going to match my
latest version. This creates a problem.
I have seen two basic reasons stated that more than one cygwin shouldn't
1) It's not an important problem
2) Tell the vendors to always ship the latest version of cygwin,
with the implied therat of losing market share.
3) It's too hard or impossible to run two cygwins.
Personally, I don't buy any of these. Of course, I haven't contributed
to this project, but over the last 35 years I have designed a lot of
systems in a lot of OS's (or designed the OS's).
As to #1, that will become a self supporting prophecy if this situation
continues. Either large numbers of folks will be using Cygwin, or they
won't. Either vendors will be releasing Cygwin based products or they
won't. If they do, and lots of people use Cygwin, it is an important
problem. If it remains a problem, Cygwin usage will go down. After all,
if I tell my vendor that I don't want their product because it is
incompatible with my system, they don't care. They have lost one sale,
but there are plenty of folks that are without Cygwin, so this is no big
deal. If a vendor gets lots of complaints, he is going to go away from
Cygwin. I wish my current vendor had just used Windows environment...
then I wouldn't be facing this issue.
#2 is ridiculous, pure and simple. Vendors aren't going to spend their
time creating and support lots of version of their software just to stay
in sync with Cygwin. And they are going to bundle cygwin because 99% of
their customers don't have it, and the vendor wants to create an easy
installation for this vast majority of their customers.
#3 I don't believe either. I have heard the argument that a cygwin
program needs to know which DLL to load and which registry entries to
use, and that just isn't possible.
But it is actually trivial. The DLL path searched starts where the
cygwin application starts, so that is one way to separate DLL's. A
single environment variable can define which registry entry to use. It
can also define the name of the shared memory segment. It could also
name the DLL, if one wanted to go that way. Hey, that's what environment
variables are: a way to define different environments for software.
Now I'm probably missing some big technical problems, but I'm curious
what they are.
I would like cygwin to allow multiple versions. I can tell from google
that others would like this too. And vendors, especially small vendors,
can greatly reduce their development costs if they can distribute
command line cygwin tools rather than developing windows kluges, which
is no doubt why we are starting to see this problem.
I multiple simultaneously functioning installs are a problem, how about
adopting a project goal that supports multiple one-at-a-time versions of
cygwin, and put the details in a faq or a shipped script?
Finally, regardless of how all this comes out, I want to thank those who
have created and continue to work on cygwin. It is a great thing to have
and I use for all of my work.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html