My 2 cents:
All modules and EPICS base should not only have version macros (i.e.
compile time version) but as well a version constant or function (link
time version), so that you can see which (dynamic) library version you
are linked to. I also opt for binary backward compatibility, so that it
is always possible to replace a dynamic library with a newer version
without needing to re-build all programs. Forcing a program to link only
with a very specific library version is, in my opinion, not very
maintenance friendly.
Dirk
On 30.10.2017 18:22, Andrew Johnson wrote:
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
- Replies:
- Re: exporting module versions Ralph Lange
- References:
- exporting module versions Michael Davidsaver
- Re: exporting module versions Andrew Johnson
- Navigate by Date:
- Prev:
Base status Andrew Johnson
- Next:
Re: exporting module versions Ralph Lange
- 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:
Re: exporting module versions Andrew Johnson
- Next:
Re: exporting module versions Ralph Lange
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024
|