Include version number in source code

[SpotlightKid]

Hi there, thanks for this awesome plugin. I had been hoping for a release of a good Open Source string machine plugin for a long time.

I'm in the process of packaging the plugin for the Arch User Repository. I'll do a package for the release version (0.1.0) and a VCS package, which always compiles the latest state of the Git repo. For the latter it would be helpful, if the version number of the software was included somewhere in the sources. so my PKGBUILD can extract it.

The obvious place would be the #define on line 8 of plugins/string-machine/DistrhoPluginInfo.h, e.g.:

#define DISTRHO_PLUGIN_VERSION         0,1,0

Also, an "install" target in the Makefile would be nice, but I guess that should be raised as an issue with DPF.

[SpotlightKid]

Here's the VCS package: https://aur.archlinux.org/packages/string-machine-git/

[jpcima]

Thank you for making the package.
Aren't you able to extract the version number from the nearest tag? Master is at v0.1.0.

A pkgver() as this one would likely work. (as copied from Arch Wiki, except deleting "v" as prefix)

git describe --long | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'

(1) regarding install, I'm leaving a user install where desired, because distributions don't adopt fixed conventions for LV2 location.
(2) providing Arch to openSUSE build service is a future option for binary packages
(3) as reported by nilshi on #lad IRC, boost is required as a makedepend.

[SpotlightKid]

If it is guaranteed, that releases will always be properly tagged in Git and the format of the tag name doesn't change, parsing the version number from the tag should be ok. My experience with other projects 've packaged is that this is often not reliable in the long run. Of course I can always change the pkgver function later, but it's good to know what's the "official" way of the project to set the version. Also, be aware that the version set in the DISTHRO header will be made available to plugin hosts.

Also, sometimes developers like to set a new higher version number for the in-development version, which wouldn't be reflected by the tag for the latest release.

Re 1) I'm fine with having manual install commands in the PKGBUILD, but you might want to have a look at how I did an install and install-user Makefile target here: https://github.com/SpotlightKid/ykchorus/blob/master/Makefile#L59

Re 2) Arch users usually are not accustomed to install binary packages from third-parties, since that doesn't integrate well with the Arch package system. IMHO it's better to make compiling from source as easy and obvious as possible for packagers.

Re 3) I'll update the dependencies. Would be nice to document these dependencies in an "Build" or "Installation" section in the readme, like you do in the https://github.com/jpcima/rezonateur project.

[jpcima]

Regarding version, I tag with the "v" prefix and operate by the semver naming scheme.
The version in-development does not bump the number.

An exception is for continuous github releases, when I add them at a future point, which use latest as a tag. So, I would finalize the pkgver() in this form. (same as I did with adlplug-git in AUR)

git describe --long --exclude latest | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'

As you suggest, I will add a rule and documentation.
A release checklist will be also desired, so I don't forget to bump the distrho plugin version.

[SpotlightKid]

Ok, thanks. Close this issue as you see fit.

[jpcima]

I will thanks. As I just observed, building the PKGBUILD from the clean chroot, it also needs libgl, since one place in DPF still requires GL/gl.h despite exclusive cairo use.

So that's libgl and boost, both as makedepends.

[SpotlightKid]

Just to confirm: these are only build-time dependencies, right? I don't see either the LV2 or VST plugin .so files link to a boost or mesa library.

[jpcima]

Just to confirm: these are only build-time dependencies, right? I don't see either the LV2 or VST plugin .so files link to a boost or mesa library.

Yes it's header-only dependencies.

• libgl for GL/gl.h included in pugl
• boost providing list structures which implement voice management

[jpcima]

Ok, I've fixed an extremely dumb bug which made filter cutoff not controlled as it should.
When this is fixed, it allowed filtering to become vastly more expressive.
1f7402d

It will warrant a new package version, but first, it will need a new set of presets, as current ones will be broken.

[SpotlightKid]

The original issue is fixed, so this can be closed, I guess.