Compiz, X11, Glib, and general stupidity

davmac

4 years ago

Advertisements

Edit/Disclaimer: I must have been having a bad day when I originally wrote this. There’s some very questionable development practice discussed here but calling people (even and perhaps especially non-specific people) “jerks” was going too far. Apologies to anyone I offended with this post.

I’m currently in the process of trying to compile compiz, the compositor/window manager for X that’s been around for a long time now under various different names. The first snag I hit was that compiz isn’t housed where you might think, that is, the compiz website; instead it seems recent versions can be found in launchpad, where presumably various folks from Ubuntu have had their way with it. In any case, I’ve downloaded the source for version 0.9.12 from launchpad. On trying to build it (with “make VERBOSE=1”) I’m seeing this error:

I am astounded; it seems there are three separate packages in which the maintainers have displayed astonishing levels of ignorance and arrogance. First, and most obviously:

Compiz have released a source bundle which doesn’t build.

Oh, I’m sure it builds on some system with modified headers, as perhaps might be found on Ubuntu systems or others, but it doesn’t build against vanilla versions of the packages on which it depends – in this case libX11 and Glib, both fairly fundamental libraries (I have the most recent released versions of both).

As bad as this, however, it pales in comparison with the bone-headedness of the developers of those packages, who have both chosen to define constants, in the global namespace, called TRUE and FALSE.

Here’s a hint, you jerks:

Don’t do that.

I’m thinking that to work around this, I’ll just add “#undef TRUE” and “#undef FALSE” before the inclusion of Xregion.h (i.e. in compiz’s core/window.h). But it’s really a huge problem that they’re defined in the first place. Macros in the global namespace are bad enough without giving them such generic names as TRUE and FALSE.

Update: I’m not certain but it looks like compiz might be using Xlib internal API by including the Xregion.h header, which is not a documented header; this puts the blame mostly on compiz if correct. Essentially it seems that Xregion.h provides the implementation for the public region operations which are defined in Xutil.h (in particular, ‘struct _Xregion’ is defined in Xregion.h, but is an opaque structure in Xutil.h). See documentation for region manipulation here.