Ivan Gyurdiev ivg231@gmail.com writes:
Note: A new file was started for this purpose: wined3d_types.h. This is _not_ the same as the one in the wine include folder - that one should be for types which appear in the interface of wined3d, and must therefore be exposed to other dlls. This one is private. I think the dll interface should be strictly enforced, so private structures have no place outside our folder.
This will cause massive confusion. There is already a wined3d_private.h file, you should put that stuff in there.
Alexandre Julliard wrote:
Ivan Gyurdiev ivg231@gmail.com writes:
Note: A new file was started for this purpose: wined3d_types.h. This is _not_ the same as the one in the wine include folder - that one should be for types which appear in the interface of wined3d, and must therefore be exposed to other dlls. This one is private. I think the dll interface should be strictly enforced, so private structures have no place outside our folder.
This will cause massive confusion. There is already a wined3d_private.h file, you should put that stuff in there.
The amount of structures added will quickly result in an unmaintainable header. There's a very clear difference between the two - wined3d_types.h would be for types equivalent to the d3d types - essentially no maintainance, simply map one-to-one to d3d. wined3d_private.h would be for shared structures that we come up with. Also, wined3d_private.h includes wined3d_types.h.
I will comply if you want it this way, but I disagree - smaller files are easier to work with. In fact, I think having a single private header per dll is probably a mistake as well.
Ivan Gyurdiev ivg231@gmail.com writes:
wined3d_types.h would be for types equivalent to the d3d types - essentially no maintainance, simply map one-to-one to d3d. wined3d_private.h would be for shared structures that we come up with. Also, wined3d_private.h includes wined3d_types.h.
I will comply if you want it this way, but I disagree - smaller files are easier to work with. In fact, I think having a single private header per dll is probably a mistake as well.
I don't have a problem with creating another file if you think that's better, but please come up with another name, don't use the same name as the global header.
Alexandre Julliard wrote:
Ivan Gyurdiev ivg231@gmail.com writes:
wined3d_types.h would be for types equivalent to the d3d types - essentially no maintainance, simply map one-to-one to d3d. wined3d_private.h would be for shared structures that we come up with. Also, wined3d_private.h includes wined3d_types.h.
I will comply if you want it this way, but I disagree - smaller files are easier to work with. In fact, I think having a single private header per dll is probably a mistake as well.
I don't have a problem with creating another file if you think that's better, but please come up with another name, don't use the same name as the global header.
Henri and Stefan, any preference? (you better have an opinion since you're making me do this in the first place :)
Am Freitag 06 Oktober 2006 04:48 schrieb Ivan Gyurdiev:
I don't have a problem with creating another file if you think that's better, but please come up with another name, don't use the same name as the global header.
Henri and Stefan, any preference? (you better have an opinion since you're making me do this in the first place :)
I do not object against putting them in include/wine/wined3d_types.h, but if the types are never meant to be used outside wined3d a header like dlls/wined3d/private_types.h is good for me too. (Or maybe a better name)
Maybe something like wined3d_private_types.h, although perhaps that's a bit long.
-
Alexandre Julliard -
H. Verbeet -
Ivan Gyurdiev -
Stefan Dösinger