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: Torsten Bögershausen <[email protected]>
To: Dirk Zimoch <[email protected]>, <[email protected]>, Timo Korhonen <[email protected]>
Date: Fri, 10 Nov 2017 08:33:16 +0100


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  <20172018  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  <20172018  2019  2020  2021  2022  2023  2024