Hi folks,
On 30 Mar 2001, at 15:39, the Illustrious Christopher Faylor wrote:
> On Fri, Mar 30, 2001 at 03:00:57PM -0500, Earnie Boyd wrote:
> >> Except what's a "msvcrt" or a "crtdll"? They're just strings of
> >> characters.
> >>
> >> Expecting people to know about these DLLs or any package name other
> >> than cygwin or (maybe) unix seems like it would still be subject to
> >> confusion.
> >
> >I expect that know one knows anything except perhaps the creator and
> >that can be said to be questionable?! ;^) Why doesn't -mno-cygwin mean
> >that no runtime is supplied at all and I have to supply my own? As you
> >can see "no-cygwin" is "just a string of characters". It has no more
> >meaning than msvcrt or crtdll and is in fact less descriptive.
>
> Presumably, if someone downloaded the Cygwin package they would be able
> to infer that an option with "no" and "cygwin" in the name might, just
> possibly, produce an executable that doesn't rely on cygwin. So, if
> they stumbled across this option in some mailing list discussion or
> other they might stand a chance of doing the right thing.
>
> The original proposal was that we have a -mmingw switch. That would
> presume that a person who wanted to produce a binary that didn't rely on
> cygwin would find -mmingw more intuitive. I don't think that a naive
> user who stumbles upon a switch named "-mmingw" is going to be more apt
> to think "Aha! That must produce native windows apps!"
>
> This applies to -mmsvcrt and -mcrtdll as well. What's a msv? What's a
> crt? Why would I care?
>
> If you are proposing that it would be a nice convenience to have these
> options for people who know what they mean, I certainly wouldn't argue.
> I just don't see how you can assert that they would make things easier
> to understand.
>
> The bottom line is that, IMO, if you have to do research to figure out
> the right option to use, then it really doesn't matter all that much
> what the option is called. Given this, IMO, the one thing that does
> make sense, is to stick with what has historically been used. For this
> reason, I think that nuking -mno-cygwin is apt to cause more confusion
> than it saves.
At this point I agree...I don't think I need to point out the innate
confusion that exists when using the -mno-cygwin switch, as that has
been amply covered.
What I would point out is that, regardless of what switch might exist
(or be named, etc.), there will still be that innate confusion.
Of course, ideally (at least to me), I would consider a "-mnon-
cygwin", "-mnon-posix" or '-mnon-unix" switch to represent basically
the same thing...the specifics of course would have to be added...and
then, if you add everything, you are now looking at using a gcc command
line invoked cross-compiler (this is _not_ pretty), as opposed to a
standard compiler...granted it's a mess any way you look at it...
So, retaining the -mno-cygwin, for much the same basic reasons that
Chris F suggests is, as far as I am concerned the better choice -- to
nuke the "-mno-cygwin" switch, imho, would be a mistake.
Anyway, there's my two-cents worth...
Peace,
Paul G.
>
> cgf
>
> P.S. Btw, -mcygwin is a valid switch.
>
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>
Nothing real can be threatened.
Nothing unreal exists.
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
