Re: -mno-cygwin

["Paul Garceau" <pgarceau@qwest.net>]

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