EPICS Home

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: Michael Davidsaver <[email protected]>
To: Dirk Zimoch <[email protected]>, [email protected]
Date: Wed, 8 Nov 2017 18:19:10 -0600
On 11/08/2017 03:20 AM, Dirk Zimoch wrote:
> On 03.11.2017 18:12, Andrew Johnson wrote:
>> On 11/03/2017 10:58 AM, Ralph Lange wrote:
>>> On Fri, Nov 3, 2017 at 3:59 PM, Dirk Zimoch <[email protected]>
>>> wrote:
>>>
>>>     I agree that all this is not easy.
>>>
>>>     Nevertheless, can we have version constants or functions in addition
>>>     to macros?
>>>
>>> Which version?
>>> Source code version? ABI version? API version? All of them? More?
> 
> So far, several programs display EPICS_VERSION_STRING or
> epicsReleaseVersion. Both are macros. Would be nice if they could be
> constants. At the moment for example medm displays in the start popup
> the EPICS version it has been compiled with, not the version it runs
> with. I noticed that when I installed patches in EPICS base and the
> EPICS_SITE_VERSION part did not update.
> 
> For example vxWorks has the global variable vxWorksVersion in addition
> to the macro VXWORKS_VERSION.
> 
> Glibc has the function gnu_get_libc_version() in addition to the
> __GLIBC__ and __GLIBC_MINOR__ macros.
> 
> At PSI I add a _<modulename>LibRelease string constant to each module
> (automatically created from CVS/GIT tags).
...

I'll make a last effort to bring this thread back around to giving
practical examples of how to export version information.

The pvDataCPP and pvAccessCPP libraries provide functions to extract
version information in numeric form.  eg.

https://github.com/epics-base/pvDataCPP/blob/master/src/pv/pvdVersion.h#L41

There is also a semi-public (at least until now) variation w/o c++ name
mangling which I thought might be helpful to someone who likes calling
dlopen() more than I do.  See Dirk, I was thinking of you!

https://github.com/epics-base/pvDataCPP/blob/master/src/pv/pvdVersion.cpp#L25


The numpy python module is an example of how something like this would
be used.  The following cross-check is done when a C extension does the
equivalent of 'import numpy'.  Which is to say, when one loadable module
depends on the C ABI of another.

https://github.com/numpy/numpy/blob/4cc8cb27e792098875edea9fa000528ca1b34f02/numpy/core/code_generators/generate_numpy_api.py#L84

Replies:
Re: exporting module versions Timo Korhonen
References:
exporting module versions Michael Davidsaver
Re: exporting module versions Andrew Johnson
Re: exporting module versions Dirk Zimoch
Re: exporting module versions Ralph Lange
Re: exporting module versions Dirk Zimoch
RE: exporting module versions Mark Rivers
Re: exporting module versions Dirk Zimoch
Re: exporting module versions Mark Rivers
Re: exporting module versions Dirk Zimoch
Re: exporting module versions Ralph Lange
Re: exporting module versions Andrew Johnson
Re: exporting module versions Dirk Zimoch

Navigate by Date:
Prev: Re: Base status Andrew Johnson
Next: Re: exporting module versions Timo Korhonen
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 Dirk Zimoch
Next: Re: exporting module versions Timo Korhonen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024