"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > I agree with this, but the two issues are completely orthogonal. > One deals with how we organize extensions, one on how to use them. > I am 100% with you that a portable implementation is better -- it > is in fact the same pattern adopted by 'configure'. However, this > says nothing about where to place such extensions. In fact, I would > argue that placing such extension in explicitly designated headers > will actually help Winelib developers. For one, it will make it a > lot more explicit when they will have to use the portable pattern > you were advocating. Otherwise, if development happens user Winelib, > this can be easily missed. Moreover, it allows projects to easily > enforce (by giving them the means to trivially check were Wine > extensions are being used) certain policies about when/where/how > Wine extensions are acceptable. > > For portability, people will have to simply do: > #ifdef __WINE__ > #include <wine/extensions.h> > #endif > > just like they do with HAVE_XXX_H tests. It fits in rather well, no?
I don't agree that the issues are orthogonal, I think that how we organize the extensions very much depends on how we want people to use them. Also I think your approach does not encourage the right pattern, it actually suggests using #ifdef __WINE__ everywhere. I think the main question is whether or not we want to encourage use of the extensions. If we want to encourage it, then they should be in the default headers; if you need some magic incantation to make them available nobody will bother. Now, if we'd rather encourage portable code that doesn't use extensions, then IMO we shouldn't export them at all, and let people who really want them go to the trouble of copying them from Wine internal headers. There's also the issue of backwards compatibility; many of the extensions are for things that aren't documented by Microsoft at this point, but that may become documented one day. If that happens and the extension is already in the standard headers then it's completely transparent; but if it's in wine/extensions.h then we'll have trouble keeping everything in sync. -- Alexandre Julliard [EMAIL PROTECTED]
