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).
Doesn't this also introduce a combinatorial problem too? If a module
like Asyn needed to alter its behaviour slightly based on the runtime
version of libCom that it's running against, wouldn't some modules
dependent on Asyn also have to do something similar? Programming is hard
enough for most people without having to add this level of complexity to
the development process.
Not necessarily. That only happens when the implementation is not
properly isolated from the interface. If lib A is used by B and B is
used by C, then C should not need to care about A. That is the whole
idea of having B. Otherwise C could use A directly.
Is there something in PSI's production environment that is pushing you
in this direction instead of accepting that you just need to rebuild
everything downstream of an update? I would recommend taking a look at
Sumo from HZB (BESSY-2) which automates all the necessary rebuilds.
- Andrew
We build every module (e.g. drivers) as dynamically loadable libraries.
We load those libraries into softIoc as provided by EPICS base. We never
build EPICS "applications". That makes it much easier to update driver
modules in case of bugs.
Years ago (when I came to PSI) people were compiling their own driver
binaries and loaded those *.o files into the vxWorks shell with ld after
loading iocCoreLib. That had several problems. Different versions of the
same driver were in use but nobody could find out which version was
witch. Only the size of the object file differed. Nobody knew which
version was up-to-date. One reason was that at that time many people
here did not use source code repositories properly -- or at all. So we
ended up having different sets of bugs in the same drivers all over the
place. Often drivers with known bugs have not been updated. If out of
laziness of fear of change I cannot say. The situation improved only
when we introduced a global driver pool and having one small group of
people responsible for maintaining drivers. This offloaded the beamline
controls people from driver programming and debugging and allowed them
to focus on record databases.
The driver pool is on NFS and contains all versions of any driver
library used by anyone. We made sure all "local" driver versions were
removed from all IOCs and all changes were integrated into the common
driver version. Per default IOCs load the latest version automatically,
assuming it has all the latest features and bug fixes. But it is
possible to explicitly load an older version. However we do not
recommend using explicit versions and do not give support for problems
with old driver versions.
Since then the "It crashes once a week. I don't know why. We simply
reboot"-problems have drastically decreased.
I got the impression that having "stable software" (i.e. nothing changes
as long as I do not rebuild) has less value that an "automatically
improving" system (i.e. to get the better version I only need to reboot).
Of course we announce changes, so people know what to look for if really
an IOC does not work any more after a reboot. And we automatically log
all module versions in a database at every IOC start. And you can ask
the IOCs what the currently loaded modules are (automatically generated
STRING waveform records).
For this setup, I would like to be able to update intermediate software
layers like asyn without breaking dependent drivers.
BTW: People here still decide manually about the EPICS base release of
their IOCs. Thus IOCs do not switch from 3.14.8 to 3.14.12
automatically. But they may automatically upgrade from 3.14.12.3 to
3.14.12.4 or to 3.14.12.3 + patches.
Dirk
- Replies:
- Re: exporting module versions Michael Davidsaver
- Re: exporting module versions Torsten Bögershausen
- 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
- Navigate by Date:
- Prev:
Jenkins build is back to normal : epics-core » mac #13 APS Jenkins
- Next:
Re: Base status Andrew Johnson
- 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 Michael Davidsaver
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024
|