1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 <2018> 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 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: EPICS Application Package |
From: | Hinko Kocevar <[email protected]> |
To: | "[email protected]" <[email protected]>, "[email protected]" <[email protected]> |
Date: | Fri, 12 Oct 2018 18:06:13 +0000 |
Dear,
On 2018-10-12 17:12:24+02:00 [email protected] wrote:
As a user of the ESS EPICS environment, I've been there. IOC was not starting due to broken dependencies not being resolved at runtime as expected, while I had nothing to do with the changes that caused my IOC to fail to start. I would recommend not to go down this path, if you have the choice, even if it seems attractive as it does. The reasons for not being in favor of such approach are purely empirical, while some folks at PSI/ESS might have a success story to share. The EPICS build system is something one needs to get used to. During the years of being involved with EPICS, I settled to have builds for the IOC and support modules to be explicitly defined in configuration files, just as EPICS build system was designed to deal with them. To avoid hand editing the RELEASE files each time I have an IOC to build, I've coded a python script that takes a 'recipe' for base/module/IOC containing some meta data, including top package dependencies, and delivers a set of built packages - found while resolving deps at compile time. The reason for sticking with the EPICS build system is mainly because I can get all the support I need from this mailing list, when things take the turn for the worse, as opposed to being more or less on my own with some customized EPICS runtime solution. YMMV. Cheers, Hinko
|