On Thu, Sep 17, 2009 at 04:36:54PM +0200, Julien Cristau wrote: > On Thu, 2009-09-17 at 21:52 +1000, Peter Hutterer wrote: > > something like a single header file specifying the supported version for all > > extensions rather than 25 SERVER_FOOBAR_MAJOR spread over different > > source files seems sensible enough to me. Any comments? > > Keeping the supported proto version in the same place as the code that > handles the extension means there isn't one more file to forget to > update when introducing new protocol, so I'm not sure separating them > wins us anything here. You don't usually extend more than one extension > at once, so I don't see a reason to keep all the versions together. I > might be missing something though. :)
One benefit of a single file is that you can see in one go what protocol versions are supported (see the recent configure.ac change). A side-effect of this is that if someone changes the version for some other protocol they are more likely to discover that another version is out of date. Example: libXfixes/configure.ac states dnl Version should match the current XFixes version. XFixesQueryVersion dnl returns the version from xfixeswire.h, NOT the version we set here. But we dnl try to keep these the same. Note that the library has an extra dnl digit in the version number to track changes which don't affect the dnl protocol, so Xfixes version l.n.m corresponds to protocol version l.n, dnl that 'revision' number appears in Xfixes.h and has to be manually dnl synchronized. configure.ac has a version of 4.0.3 the actual revision number define is 1 (back from 3.0.1). In between we had 4.0.0, 4.0.1 (woohoo, revision number define was correct agin), and 4.0.2. libXcomposite has the same issue with revision defined as 2 since the golden days of 0.2.2. We had 0.3.0, 0.3.1, 0.3.2 and 0.4.0 since. The point of these examples is that maintaining version defines seems to be difficult. Having them somewhere where others see them too even if they're not working on that code might just help a bit. But the real killer feature for me is the single-page list with all server-supported protocol extension versions. Which would nearly count as documentation. Cheers, Peter _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
