2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 <2017> 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 <2017> 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: exporting module versions |
From: | Dirk Zimoch <[email protected]> |
To: | <[email protected]> |
Date: | Wed, 8 Nov 2017 10:20:48 +0100 |
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