EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: exporting module versions
From: Dirk Zimoch <[email protected]>
To: <[email protected]>
Date: Thu, 2 Nov 2017 10:23:55 +0100
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  <20172018  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  <20172018  2019  2020  2021  2022  2023  2024 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·