These were issues that made my eyes bleed when I last looked at them. After wiping away my red tears, I promptly dug a hole and buried my head. You're certainly a man of higher constitution that I can claim.
I promise you beer in Portland for this... Sure, I owe you beer in general, but one of them will be for this! Cheers, Jeremy On Jun 24, 2009, at 22:26, Peter Hutterer wrote: > > This is a patch series to clean up the xextproto repository. > > The problem with it now is that it mixes library headers with protocol > header. This is partly mitigated by amusing requirements to define > random > variables before including the file to ensure you're only including > the Xlib > header part, or just the protocol part, or random other bits. > > The runner-up is XShm.h, which includes the few lines that apply to > the > server in an #else clause. So the protocol headers have include > lines for > server internal headers. > http://cgit.freedesktop.org/xorg/proto/xextproto/tree/XShm.h > > The winner of this week's grand prize is sync.h, which declares Xlib > functions, then #defines macros with the same name so that callers > need to > undef them at will to get the functions instead of the macros. I > don't know > the purpose of this and I didn't try to fix it, at this point I > started > stabbing myself to make the pain go away. > http://cgit.freedesktop.org/xorg/proto/xextproto/tree/sync.h > > 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. > > So any client users of Foo.h should be mostly fine, they get the same > defines. In the server there was more work, since the server now > needs to > include Fooconst.h and Foostr.h instead of Foo.h > This also affects at least xfixesproto that has a #include <shape.h>. > > This is in theory anyway, there will be breakages in some clients. > This is a > tricky situation, since getting it to a point where there are no > breakages > on the client side is quite hard given the combinations of ifdefs > possible. > > Since this is an API break only, not an ABI break, I propose pushing > this to > git and bumping to a pre-relase for xextproto-7.1, then fixing up the > libraries as they come. > > Comments? Review of the patches would be much appreciated. > > Cheers, > Peter > _______________________________________________ > xorg-devel mailing list > [email protected] > http://lists.x.org/mailman/listinfo/xorg-devel _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
