[PATCH 00/18] xextproto repository cleanup

[Peter Hutterer]

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