Experimental Physics and Industrial Control System
On 09/11/17 01:19, "[email protected] on behalf of Michael
Davidsaver" <[email protected] on behalf of
[email protected]> 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 <[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.
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>
2018
2019
2020
2021
2022
2023
2024
- 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>
2018
2019
2020
2021
2022
2023
2024