RE: [RFC] Adding an include/wine/wine directory?

[Patrik Stridvall]

> Patrik Stridvall  writes:
> > I would like to have a directory structure like
> >
> > include: Wine's version of Windows headers
> > include/wine: Wine's internal headers
> > include/wine/wine: Wine's "extension" headers
> >
> > With "extension" headers I mean that headers that
> > are exported and usuable by Winelib applications.
>
> That's ugly IMO.

The specific solution above, perhaps.

However I think it would be very useful to make a proper distinction between

1. The Wine version of Microsoft headers
2. Anything that Wine uses to communicate internal
3. Extensions that Winelib applications can use.

Perhaps (2) and (3) are not much different (se below),
but (1) and (2/3) are clearly different.

That is why I think "-I../../include" shouldn't automatically give
you (2) and (3) as it does now. Having to add -I../../include/wine
or whatever to get it would make it possible in addition to
solving my MSVC Microsoft header problem to make it possible to
uses the Microsoft headers or whomevers headers even on Linux.
> Besides there is no such distinction between internal
> and "extension" headers, all the headers in include/wine are supposed
> to be usable by Winelib app.

Sure there are. Not all header from include/wine are copied
to /usr/local/include/wine/wine during. The ones that are not
copied are "internal" and the ones there are are "extensions"
in some meaning.

Only the "exension" headers (ie header that are copied during
install) can be used by Winelib applications.

However that might perhaps only be a temporary distiction.

Anyway

cd include/wine
mkdir wine
mv *.h wine

work for me as well if you prefer that.
> I'd suggest you simply copy the ones you
> need with MSVC somewhere else to avoid conflicts.

Hmm. Yes, that is another possibillity (read: kludge).

Don't really like copying source files around,
but it would work (with the possible exception
of dependecies, but then "Rebuild all" is your
friend :-).

In short:
I still think that we should require another -I to
access the Wine specific (internal and extension)
headers.

However I don't really care if we do

(1) -I$(TOPSRCDIR)/include -I$(TOPSRCDIR)/include/wine
(2) -I$(TOPSRCDIR)/include -I$(TOPSRCDIR)/$(WHATEVER)

I just don't think just doing -I$(TOPSRCDIR)/include like
now is good for the reasons given above and below.

Sometime you only want the Wine specific header sometimes
you only want Wine's version of the Windows header.
"Forcing" everybody to take them as a package only gives
rise to unnessary problem like the one I'm trying to solve.

Sure I could kludge it, but why not try to solve it properly?

[RFC] Adding an include/wine/wine directory?

[Alexandre Julliard]

Patrik Stridvall  writes:
> Perhaps (2) and (3) are not much different (se below),
> but (1) and (2/3) are clearly different.

Well yes, that why they are in different directories. (1) is in
include and (2/3) is in include/wine.
> That is why I think "-I../../include" shouldn't automatically give
> you (2) and (3) as it does now. Having to add -I../../include/wine
> or whatever to get it would make it possible in addition to
> solving my MSVC Microsoft header problem to make it possible to
> uses the Microsoft headers or whomevers headers even on Linux.

The problem is that then you require everybody who wants to use
Winelib to add stuff to their include path, even if they don't use any
Wine header directly (since our Windows headers reference the Wine
ones). So you are making the normal case more complex to simplify the
very unusual case of mixing headers. I prefer to ask people who want
to mix headers to do some extra steps and make the common case as easy
as possible.

[RFC] Adding an include/wine/wine directory?

[Steven Edwards]

> That is why I think "-I../../include" shouldn't automatically give
> you (2) and (3) as it does now. Having to add -I../../include/wine
> or whatever to get it would make it possible in addition to
> solving my MSVC Microsoft header problem to make it possible to
> uses the Microsoft headers or whomevers headers even on Linux.

I would really also like I easy way to be able to use/see where the Mingw/W32api package is hosed
rather then using the WINE headers. ATM if I want to work on porting a DLL then we have to fork
the hell out of it to see where the headers a hosed.

Thanks
Steven

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/