Re: Fw: [MinGW-dvlpr] [Fwd: [Mingw-users] BYTE_ORDER in mingw headers?]

[Earnie B. <ear...@ya...>]

"Steve D. Perkins" wrote:
> 
> > Cygwin has:
> > BoydE@DU211344 ~
> > $ grep BYTE_ORDER /usr/include -r
> > /usr/include/sys/param.h:#define BYTE_ORDER     LITTLE_ENDIAN
> >
> > so as far as Cygwin itself is concerned it's already covered.  I hope
> > we're not moving closer.
> 
>     I'm not sure that I understand the concern you're expressing.  The
> concern that I expressed was that updating this '/sys/param.h' include would
> reduce our compatibility with Cygwin.  It seems the exact opposite is true,
> and I am puzzled as to why that would be a bad thing.
> 

I don't know that /sys/param.h is "a bad thing", I don't know that in
light of MinGW that it's a good thing either.

>     I was under the impression that MinGW's "mission statement" (or as close
> as we have to one) is to produce a runtime for Cygwin's gcc that removes
> dependence on the Cygwin DLL.  This has morphed a bit (with no formal
> declaration of direction), to include a binary implementation of gcc and now
> a shell environment in which to work.
> 

Well, really it's more to provide a dispersible set of files usable
against the vendor supplied runtimes.  It started with the runtime files
not to shortly to be used to create version of GCC that used that
runtime and produced executables using that runtime.  You're correct
about the informal direction with which MinGW has evolved.

>     However, the fact remains that Cygwin's userbase dwarfs that of MinGW at
> this time.  

Are you saying that Cygwin has fewer users than MinGW?  Or is it that
MinGW has fewer users than Cygwin?

> The only reason countless applications and libraries
> successfully build on MinGW is that MinGW is "close enough" to the Cygwin
> target.  

Let's see

	Cygwin		MinGW
ANSI	  X		  X
POSIX	  X

Seems the difference is that Cygwin supports POSIX while MinGW doesn't. 
MSYS provides enough of POSIX to have an environment to execute scripts
but not enough to have a POSIX runtime.

> I do not see a significant number of application/library producers
> going far out of their way to produce MinGW-specific targets.  It is my fear
> that if we depart from the Cygwin implementation far enough to FORCE these
> producers into making a decision on whether or not to specifically target
> MinGW, we may be quite disappointed with the decisions made.
> 

I don't understand.  MinGW has never been easily configurable until
now.  I want to aid that configuration if possible.  Adam has found that
BYTE_ORDER is needed to determine endianess by autoconfigurization.  He
offered a potential fix.  My concern with that fix is that it moves away
from what we've standardized on in the past for runtime files.  My
concern is that neither BYTE_ORDER or sys/param.h is ANSI compliant nor
are they MS compliant.  My concern for not including them is that they
cause problems for the GNU autoconfigurization tools.  MinGW already has
some non-ANSI/non-MS coding.  The question is, do we allow this
non-ANSI/non-MS feature to happen.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com