Alexandre Julliard wrote:
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.
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