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. > 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. -- Alexandre Julliard [EMAIL PROTECTED]