www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Libraries, versions, API changes, and Dub

reply Russel Winder <russel winder.org.uk> writes:
It appears that libdvbv5 has undergone an (unnoticed by me till just now)
version change. This raises a general question for creators of D bindings.

libdvbv5 has versions 1.12.x, 1.14.x, 1.16.x, etc, following the "odd is
internal, even is released" minor version number strategy. It seems wrong
somehow to follow that numbering for the D binding; the binding needs to ha=
ve
a separate evolution. However the binding has to allow the user to choose t=
he
major.minor number of the underlying library they have =E2=80=93 though tha=
t should
perhaps be done automatically using the pkg-config system. =20

Has anyone had previous experience of this situation and can give
advice/direction so I don't have to build a solution from first principles?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Jan 09 2019
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 10 January 2019 at 05:44:22 UTC, Russel Winder wrote:

 It appears that libdvbv5 has undergone an (unnoticed by me till 
 just now) version change. This raises a general question for 
 creators of D bindings.

 libdvbv5 has versions 1.12.x, 1.14.x, 1.16.x, etc, following 
 the "odd is internal, even is released" minor version number 
 strategy. It seems wrong somehow to follow that numbering for 
 the D binding; the binding needs to have a separate evolution. 
 However the binding has to allow the user to choose the 
 major.minor number of the underlying library they have – though 
 that should perhaps be done automatically using the pkg-config 
 system.

 Has anyone had previous experience of this situation and can 
 give advice/direction so I don't have to build a solution from 
 first principles?


Use version conditions for the different library versions to set 
up compile-time versions you can static if on:

```
enum DVBVSupport {
     v112  = 112,
     v114  = 114,
     v116  = 116,
}

version(DVBV_114) {
     enum dvbvSupport = DVBVSupport.v114;
}
else version(DVBV_116) {
     enum dvbvSupport = DVBVSupport.v116;
}
else enum dvbvSupport = DVBVSupport.v114;

// Declarations supported in 1.12
...

static if(dvbvSupport >= DVBVSupport.v114) {
...
}

static if(dvbvSupport >= DVBVSupport.v116) {
...
}
```

This is how I handle it in the BindBC libraries, to which I'm 
porting all the active bindings from the DerelictOrg group (where 
I handled it with different git branches, which is a horribly 
confusing and inefficient way to go about it):

https://github.com/BindBC

The only drawback to it right now is that static if isn't 
supported inside enum declarations, so you'll wind up with 
multiple declarations of the enum, as I did with SDL_EventType 
here:

https://github.com/BindBC/bindbc-sdl/blob/master/source/bindbc/sdl/bind/sdlevents.d#L25

static if *is* supported in class & struct delcarations, though, 
and you can see it used in that same file in some of the event 
types, like SDL_MouseButtonEvent and SDL_MouseWheelEvent:

https://github.com/BindBC/bindbc-sdl/blob/master/source/bindbc/sdl/bind/sdlevents.d#L347
Jan 10 2019
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 10 January 2019 at 10:28:55 UTC, Mike Parker wrote:


 to set up compile-time versions


Compile-time *values*


 else enum dvbvSupport = DVBVSupport.v114;


This, of course, should be = DVBVSupport.v112
Jan 10 2019
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-01-10 06:44, Russel Winder wrote:

 It appears that libdvbv5 has undergone an (unnoticed by me till just now)
 version change. This raises a general question for creators of D bindings.
 
 libdvbv5 has versions 1.12.x, 1.14.x, 1.16.x, etc, following the "odd is
 internal, even is released" minor version number strategy. It seems wrong
 somehow to follow that numbering for the D binding; the binding needs to have
 a separate evolution. However the binding has to allow the user to choose the
 major.minor number of the underlying library they have – though that should
 perhaps be done automatically using the pkg-config system.
 
 Has anyone had previous experience of this situation and can give
 advice/direction so I don't have to build a solution from first principles?


If you only support one version of libdvbv5 for each version of the 
bindings, it will be much easier. If someone wants to use an older 
version of libdvbv5 than the bindings support they can use and older 
version of the bindings.

But as long as symbols aren't removed in later versions of libdvbv5 the 
newest versions of the bindings can be used. Even if a symbol is 
removed, it shouldn't be a problem until it's used.

As for setting the version on the bindings you can do something like: 
1.0.0+1.16.0. Where "1.0.0" is the version of the bindings and "1.16.0" 
is the version of libdvbv5 the bindings support. Anything after "+" in 
semantic versioning is metadata and doesn't have any affect.

-- 
/Jacob Carlborg
Jan 10 2019