Bidi B patch

[Shachar Shemesh]

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.

Alexandre Julliard wrote:

>Shachar Shemesh <wine-devel at shemesh.biz> writes:
>  
>
>>The reason I did was to reduce confusion. The usual includes are
>>standard includes, and can be included with either <> or "". The new
>>include (gdibidi.h) is a local include, and can only be included with
>>"". To differentiate the two, I changed those who could afford a <>.
>>    
>>
>
>Local includes can be included with <> too,
>
Only because we add "-I." to the compilation flags. Adding "-I." to the 
compilation flags should not be necessary.

> there's no reason to make
>a distinction.
>
Well, there is the minor point of "what do I mean by...". I don't think 
semantic hints are something to be discarded so easily.

> And some of the headers in include/ are actually
>internal, like gdi.h (actually I would argue that bidi definitions
>should go there).
>
I placed them under the GDI directory, following what I thought was 
someone else's example. As chance would have it, I don't know what was that.

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.

> 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? I made the original change under the recollection that 
changing them all was, in fact, the future plan. As such, I though I'll 
mark this particular file as "already translated", so that they know not 
to change "gdibidi.h", and thus break compilation.

> Changing only a few here and there creates a lot more
>confusion than it solves.
>  
>
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?). We don't want it to hold directories not 
available for the standard windows. In order to enforce this 
distinction, we need to remove the "-I." from the compilation options. 
The last stage, of changing "" to <> can then happen slowly.

             Shachar

-- 
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/