Bidi B patch

[Shachar Shemesh]

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/