On Wed, Jun 24, 2009 at 11:34:52PM -0700, Keith Packard wrote: > On Thu, 2009-06-25 at 15:26 +1000, Peter Hutterer wrote: > > > Anyway. The approach in this patch series is the following: > > for any header file Foo.h, if Foo.h is a (or contains) Xlib headers > > - remove protocol constants into a Fooconst.h > > - move protocol structures into a Foostr.h (or add to it if exists) > > - move the leftover Foo.h to libXext/include and include Fooconst.h from the > > file. > > The 'new' approach has been to create three files for extension <foo>: > > <foo>.h - constants used by the wire encoding and Xlib API > > X<foo>.h - Xlib API defines (this must include <foo>.h>) > > <foo>proto.h - protocol structures for the wire encoding > (this must include <foo>.h) > > Apps do: > > #include <X11/extensions/X<foo>.h> > > The Xlib code does: > > #include <X11/extensions/X<foo>.h> > #include <X11/extensions/<foo>proto.h> > > The X server does: > > #include <X11/extensions/<foo>proto.h> > > From what I can tell, you're following the general convention, but using > different naming, right?
that was my original plan, but: xextproto uses some client headers that don't follow the X<foo>.h naming. e.g. dmps.h, sync.h. Changing this breaks all clients, hence the need for <foo>const.h. xextproto already uses some protocol headers that use <foo>str.h instead of <foo>proto.h (there's only one proto.h). That's why I decided to go with str.h. Renaming that is trivial though, I don't care either way. Consistency within the protocol package would be nice though. Both items can be fixed and I don't mind doing it, but it all depends whether/how much we want to break existing clients. In this patch series, none of the <foo>str.h include <foo>const.h right now, so that definitely needs fixing. Cheers, Peter _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
