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@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