Bidi B patch
Shachar Shemesh
wine-devel at shemesh.biz
Wed Jun 25 15:01:39 CDT 2003
Alexandre Julliard wrote:
>Shachar Shemesh <wine-devel at shemesh.biz> writes:
>
>
>>First I want to clarify something. Nothing in this email is meant to
>>suggest that I think the bidi change should, in any way, depend on
>>this issue. If you want, I can even amend my patch.
>>
>>
>
>Yes please.
>
>
Wilco.
>>Only because we add "-I." to the compilation flags. Adding "-I." to
>>the compilation flags should not be necessary.
>>
>>
>It is necessary, this has been discussed before.
>
>
I'll try to find the discussion (if someone has a handy pointer - it
would be greatly apretiated), but if it turns out that it is necessary
because we use "" instead of <>, I don't think that counts ;-)
>>In any case, it makes much sense to me not to place non-exported
>>headers in include. The idea is that you can tell packagers to take
>>the entire "include" directory and ship it. Unless I misunderstand,
>>and winelib apps actually NEED gdi.h, we do not wish to have it
>>packaged. This leaves packagers with zen decisions - not a good thing.
>>
>>
>
>gdi.h will be moved to dlls/gdi at some point. Which of course means
>that if we do things the way you suggest we then need to go back into
>all files and change <> back to "".
>
>
No. It just means we shouldn't change it to <>, now or ever.
>>>The fact is that all our source files use "" for
>>>both internal and exported headers, and we are not going to change all
>>>of them.
>>>
>>>
>>>
>>Why not, really?
>>
>>
>
>Because it isn't broken. We need to fix exported headers to use <>
>since it can make a difference in Winelib apps that use them; but in
>Wine source files "" works just as well as <>.
>
>
Ok, how about if I send you a perl program that goes over the wine
include folder, searches for each file found there in the MS SDK, and
builds a list of exported headers. It will then go over the wine source,
and change only those headers from "" to <>. This way, no manual work,
no changing "" to <> and then back (as gdi.h will, obviously, not be in
that list), and we have a clear consistant policy that makes sense. This
also solves the winelib problem you mentioned.
>>Alexandre, I only partially agree. I think the current situation,
>>where "" and <> behave the same, is an undesireable one. We want to be
>>able to tell packagers to grab the entire /include directory with no
>>fear (libwine-devel.rpm anyone?).
>>
>>
>
>Yes, include/ should contain only exported headers, it's part of the
>dll separation work, we are getting there. It's completely orthogonal
>to whether we use <> or "" to include them.
>
>
>
I can see why you say that, but I feel it narrows the discussion down to
technical (will or will not compile) consideration only. I think that we
also need to show commitment to separating inner from exported, and
this, to me, means the source too.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
More information about the wine-devel
mailing list