Experimental Physics and Industrial Control System
On 08/11/17 10:20, 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).
We have introduced something similar for 1 (!) of out modules.
It is so far only a log printout in the iocsh:
#Loading a version from a known Git commit:
ECMCPortConfigure:303 XXXX version=d14c05ee2
# Loadinga version from a known Git commit with local changes:
ECMCPortConfigure:303 XXXX version=dirty-a523dbbd9
Dirk (and/or Timo?),
is there a way that can get the pleasure to smell code ?
IOW, do you have Makefiles, scripts, local changes, Git diff
to share with us ?
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
- 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: exporting module versions Timo Korhonen
- Next:
Travis Builds of Base 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 Timo Korhonen
- Next:
Build failed in Jenkins: epics-base-3.16-sol-test #137 APS Jenkins
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024