Thomas Winischhofer wrote:
Jens Owen wrote:

Thomas Winischhofer wrote:


Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the same style as XORG_VERSION_CURRENT so that changes like the types from drmHandle -> drm_handle_t can be handled smoothly with the C preprocessor for older versions?


Point being: I would like to compile my DDX driver with both XFree86 and X.org as I don't have time to maintain two or more versions. Since the preprocessor can't check for typedefs (AFAIK...) a DRI_VERSION_CURRENT would come extremely handy.

That shouldn't cause too much hassle...



Thomas,

Versioning has always been a tricky issue for DRI developers, and consequently keeping version numbering simple and up to date is important.

I'd encourage you to considering using/enhancing the existing DRI and DRM versioning. For example, I'm wondering if the runtime version already built into DRM would help. It could be extended to use compile time #define's in places where we currently hard code constants, for example in drmGetLibVersion it looks like the minor version was just bumped to 2. The source for the linux version of this example be seen at:

  xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c


Jens, thanks for your response.

Just to avoid a misunderstanding: This version definition is not meant as an ABI/API/whatever number; I'd just need that for compilation reasons.

If it is complicated for the DRI folks, why not keep such a version #definition in the x.org tree which is updated each time a merge from the DRI tree happens?

For example, in xf86drm.h just add

#define DRI_DATE 20040616

That would solve my particular problem quite easily. The name of the #define is entirely up to you... choose freely. The date format should be in a form suitable for comparison.

That isn't too much work, is it?

Thomas


Thomas,

Adding the define is easy, what's difficult is cleaning up these little hacks later without breaking binary compatability. As Keith W. suggested earlier this week, there is a good chance the X portion of the DRI development could end up in the X.org project. What would you set the DRI_DATE string to then?

Perhaps it's time to bump the XORG_VERSION_CURRENT string to differentiate between the last release of X.org and the next. Would that help you?

--
                               /\
         Jens Owen            /  \/\ _
  [EMAIL PROTECTED]  /    \ \ \   Steamboat Springs, Colorado



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to