Shachar Shemesh wine-devel@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.
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.
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 "".
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 <>.
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.