Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Re: exporting module versions
From: Timo Korhonen <Timo.Korhonen@esss.se>
To: Michael Davidsaver <mdavidsaver@gmail.com>, Dirk Zimoch <dirk.zimoch@psi.ch>, "core-talk@aps.anl.gov" <core-talk@aps.anl.gov>
Date: Thu, 9 Nov 2017 09:54:49 +0000
On 09/11/17 01:19, "core-talk-bounces@aps.anl.gov on behalf of Michael
Davidsaver" <core-talk-bounces@aps.anl.gov on behalf of
mdavidsaver@gmail.com> wrote:


>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 <dirk.zimoch@psi.ch>
>>>> 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.

I subscribed to core-talk yesterday just to be able to reply to this
thread... ;-)

I would not like to hijack the thread again but I just would like to say
that having used the system that Dirk described for ~10 years (if I count
correctly) I can confirm everything that was written in his email. This is
why we at ESS opted to have a similar system and follow closely what Dirk
has done. We cannot simply duplicate why he has, though.

In our case we have IOC developers working in places that we have very
little control on, with various level of experience and various styles.
Thinking of the integration work when we start getting things back from
our remote contributors (which will start soon and continue for several
years), I would like to avoid the chaos of trying to figure out what
drivers and what versions have been used, where did the source code come
from, etc.  Recompiling is fine, but what are we compiling?

I was not aware of Sumo until I read this chain. I just read the
documentation quickly and cannot comment much yet but yes, it looks nice
and well thought of. But I still think Dirk's solution would match our
situation better.
The other side of the coin is that following that concept requires an
organisation that is able to handle the driver infrastructure. We have had
(and still have) challenges to build that support up.

Sorry for the hijacking. This was just for the record.


Timo

>
>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#L4
>1
>
>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/4cc8cb27e792098875edea9fa000528ca1b34f
>02/numpy/core/code_generators/generate_numpy_api.py#L84


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
Re: exporting module versions Michael Davidsaver

Navigate by Date:
Prev: Re: exporting module versions Michael Davidsaver
Next: Re: exporting module versions Torsten Bögershausen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: Re: exporting module versions Michael Davidsaver
Next: Re: exporting module versions Torsten Bögershausen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 10 Nov 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·