wine / uncode header can be remove any time.
and it shall only be use for wine part, this header take over the orginal
headers of unicode.h
it is not a accpect solvtions. as steven say and others.
----- Original Message -----
From: "Steven Edwards" <winehacker(a)gmail.com>
To: "ReactOS Development List" <ros-dev(a)reactos.org>
Sent: Monday, August 20, 2007 8:02 PM
Subject: Re: [ros-dev] [ros-diffs] [cfinck]
28423: -Alwaysinclude"wine/unicode.h" before all other headers,when we need
the wchar_t type. unicode.h includes windef.h,which includes winnt.h,which
has the handling for the wchar_t type. As it's the firstinc
On 8/20/07, Colin Finck <mail(a)colinfinck.de>
wrote:
> If you look in glibc's "stddef.h" (for example here:
>
http://tinyurl.com/yv6s9b), you find 32 checks for the existence of the
> wchar_t type.
> We'll probably never need all of them, but this just shows that almost
every
> host needs its own check.
> And adding all these definitions to the Makefile of every app, which
needs
them, is a
huge overkill in my opinion. This is why I prefer putting all
checks into "winnt.h".
I agree its a pain but it seems like a GNUism we have to live with. I
mean any other project we import in to the tree is going to have the
same problem if it uses the wchar_t type right? So we would have to
change the include order with them as well. Couldn't we add some magic
to rbuild to make it act like configure, detect the host and then pass
this to the makefile by just globally add a -D($HOST_WCHAR_DEFINE)
like we do with other compiler flags?
Sorry if I am way off base, I admit I have not looked in to the
problem in depth, I am just trying to avoid long term hassle. As it
stands now the Wine guys are reluctant to change things just for
ReactOS and also reluctant to change things that already work on
multiple host platforms.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev