Bidi B patch
Shachar Shemesh
wine-devel at shemesh.biz
Wed Jun 25 14:11:40 CDT 2003
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 at 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
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
More information about the wine-devel
mailing list