RejectedSoftware Forums

On 31.01.18 18:50, Russel Winder wrote:

SCons, Autotools, CMake, Meson, and others all assume the current application (or library) version is specified in the build configuration file. This can be transferred to being embedded in the executable by stream editing a template file and compiling it in.

Dub appears not to support this way of working, unless of course I am just missing it.

So what is the way of specifying the application version in Dub builds, and what is the canonical way of getting this data into the built executable?

Thanks for this question!(http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/16990/).

I think at least some people work by running custom preBuildCommands. I
did a small d-program that takes git describe as input but it also could
take information from dub.sdl/json (although I think git information is
better suited).
For me this solution does not really scale (I would like to have
versions also in libraries that I pull in, thats why I asked the
mentioned question).

It would be great if there is general way in dub to handle this usecase.

Christian Köstlin

On 01.02.18 22:44, Jacob Carlborg wrote:

On 2018-01-31 18:50, Russel Winder wrote:

SCons, Autotools, CMake, Meson, and others all assume the current
application (or library) version is specified in the build
configuration file. This can be transferred to being embedded in the
executable by stream editing a template file and compiling it in.

Dub appears not to support this way of working, unless of course I am
just missing it.

So what is the way of specifying the application version in Dub
builds, and what is the canonical way of getting this data into the
built executable?

I use a preGenerateCommand that outputs the version to a file [1]. Then
using an import expression to get the version into the executable [2].

[1] https://github.com/jacob-carlborg/dstep/blob/master/dub.json#L18
[2]
https://github.com/jacob-carlborg/dstep/blob/master/dstep/Configuration.d#L18

Does this also work for you when you add versions to libraries?
Is $PACKAGE_DIR always set to the package, that is just build?
e.g. an executable has a dependency to a libarary with a version.

Jacob,

Thanks for that example. SCons, CMake, and Meson tend to prioritize the stream edit a template file way of creating a configuration file and it is easy to fall into that model. Now to get them to write files for string import so that the same system is used as with Dub.

On 2018-02-02 17:41, Russel Winder wrote:

There seems to be nothing better than having a VERSION file in the filestore and no mention of version in the build specification. Simple and controllable.

The advantage of generating the file using "git describe" is that one
does not have to repeat the version in the file and in a git tag. Also
if you're building on a commit that does not have a tag associated with
it, it will give back a different version, i.e. the latest tag + a hash.

/Jacob Carlborg

On Mon, 05 Feb 2018 09:54:11 GMT, Russel Winder wrote:

The disadvantage of using git describe at build time is that it only works within a Git repository. Once a release is created you are building from a tarball and so all the data has to be in the tarball. To have different build strategies for "from repo" and "from tarball" is more complicated than ensuring the file and the git tag of the repo are in harmony.

Unless I am missing something.

I'm not building my releases from a tarball so I don't have that problem.

Note that with Dub one does not specify the version in the recipe file, instead it's the Git tag that sets the version of the Dub package.

/Jacob Carlborg