Experimental Physics and Industrial Control System

Hi Michael,

On 10/30/2017 10:39 AM, Michael Davidsaver wrote:
> I think that any module which exports an API should be exporting its
> version number.  This simplifies managing API changes in dependent code.
>  Base has been doing this for a long time, both as a header file
> (epicsVersion.h) and Make variables (cf. configure/CONFIG_BASE_VERSION).

In general I am in agreement with you over the desirability of this, I
just have a couple of modifications I'd like to see, and a suggestion on
how to spread the idea.

> As I recently went through this exercise with the pvDataCPP and
> pvAccessCPP modules I thought it might be worth explaining a recipe for
> support modules to do the same while keeping the version number in only
> one place.
> 
> The components of version number are kept in "configure/CONFIG_PVD"
> which is installed as "$(INSTALL_LOCATION/cfg/CONFIG_PVD".  This file
> will be automatically included in dependent builds since at least
> 3.14.12.4 (and maybe back to 3.14.10).
> 
> https://github.com/epics-base/pvDataCPP/blob/master/configure/CONFIG_PVD

CONFIG_PVDATA_VERSION please — you already pointed to the filename
CONFIG_BASE_VERSION, but then you chose a filename for yours that is
comparatively obscure and doesn't follow the same pattern. I might
accept CONFIG_PVD_VERSION but I see no real reason to pick the shorter
name, it just encourages unnecessary brevity and increases the
likelihood of name clashes if sites point INSTALL_LOCATION to the same
location for multiple modules.

Note that this file doesn't need to appear in the module's configure
directory, and actually I would prefer that it not for a reason I will
explain below.

> CONFIG_PVD is installed using
> 
> https://github.com/epics-base/pvDataCPP/blob/master/configure/Makefile#L5
> 
> The next step is to push the version number into a C header.  For PVD I
> chose to have a two part header, with one part being generated from a
> template (pvdVersionNum.h) and the other static (pvdVersion.h).  This
> could also be done with only the one file, as with epicsVersion.h.
> 
> https://github.com/epics-base/pvDataCPP/blob/master/src/pv/pvdVersionNum.h%40
> 
> The rules to expand this template (using expandVars.pl from Base):
> 
> https://github.com/epics-base/pvDataCPP/blob/master/src/Makefile#L34
> 
> Note that the library SONAME is also set to the release version.  This
> is a safe default for those who don't want to think ABI versioning.
> 
> The header is installed as well:
> 
> https://github.com/epics-base/pvDataCPP/blob/master/src/pv/Makefile#L15

The best way to demonstrate and encourage this kind of change to EPICS
modules is to implement it in the makeBaseApp templates. This is why the
CONFIG_<name>_VERSION file needs to go into an App/src directory,
because the template name expansion only works for files inside an App
sub-tree. Template files that appear in the configure directory get
copied to the target tree verbatim without any ability to rename them.

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Replies:

Re: exporting module versions Dirk Zimoch

References:

exporting module versions Michael Davidsaver

Navigate by Date:

Prev: exporting module versions Michael Davidsaver

Next: Build failed in Jenkins: epics-base-3.16-sol-test #137 APS Jenkins

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: exporting module versions Michael Davidsaver

Next: Re: exporting module versions Dirk Zimoch

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024