This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Supporting Open Source software


I'd like to say a few words about the small flap I caused with my
"Is -mno-cygwin support being dropped?". It goes without saying
that on the whole, cygwin is a great product, and is of big
benefit to many many people. In fact, so many people now
rely on cygwin that it is really more than a simple open
source project. It is an essential tool, and requires
special support beyond what may be required for other
open source software.

I also support an open source software product, and have thousand
of users. They all depend on me and the others who are working on
the V and VIDE software to try to keep it current and at least
let them know if there are problems. I think one of the most
important aspects is to be sure new releases don't break apps 
that already exist.

I think as a developer of a library, there is a extra obligation
in this respect. I think the Cygwin team, as the developers of
an even more important tool, a compiler, have an even greater 
obligation in this respect.

I would consider releasing a compiler that will no longer compile
projects that used to work a _major_ problem. If people are
depending on the tool, they should at least know when to abandon
the latest release and revert to the old one.

Apparently the -mno-cygwin problem has been around for well
over a month. It may be that Mumit Kahn is the only one who
can fix the problem, but even that is not clear. It seems
that some important directories have been moved, and that
there is a real problem picking up the right include paths
and libraries are linked with the -mno-cygwin option.

The problem doesn't show up for all -mno-cygwin programs,
and I find this VERY scary. The problem has to do with
getting improper files included and linked, and just
because some -mno-cygwin programs can compile, it seems
very possible that they still aren't using the correct
libraries or includes, and could have subtle problems.
In my opinion, if the full implications of the problem
aren't known, it should warrant the recall of
the latest net version of cygwin. One simply does
not release and continue to keep available broken compilers!

We all understand that all the cygwin people are busy.
We are all busy too. I think it is totally improper to
respond to unpleasant bug reports like this with
"You don't like it, fix it yourself!" I certainly don't expect
you to learn how to build my open source software.
I expect you to let me know if I've released something
broken. And since my software is a building block
that you rely on, I'll try to fix it asap. Or,
I'll at least tell you that some part is broken,
and not to use it.

Compilers are a special kind of software product.
They are the one thing that the rest of us rely on.
If the -mno-cygwin switch is not 100% reliable
(and it is quite possible that it is currently
0% reliable), then RECALL the compiler and disable
the -mno-cygwin switch until you have it fixed!
-- 

Bruce E. Wampler, Ph.D.

Author of the V C++ GUI Framework

e-mail: mailto:bruce@objectcentral.com
web:    http://www.objectcentral.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]