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
|