Re: Bidi B patch

[Shachar Shemesh]

Alexandre Julliard wrote:

Shachar Shemesh <[EMAIL PROTECTED]> 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/