| 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 2025 | 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 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: FW: EPICS 3.15.1 |
| From: | Ralph Lange <[email protected]> |
| To: | EPICS Tech-Talk <[email protected]> |
| Date: | Wed, 03 Dec 2014 16:58:55 +0100 |
While we're at it... On 03/12/2014 16:44, Mooney, Tim M. wrote:
For any synApps module, you should include <module>Support.dbd, and not <module>.dbd, because <module>.dbd is what the module builds for its own use, while <module>Support.dbd is what it builds for export to other modules. For autosave, the names are as.dbd and asSupport.dbd.
This is indeed the synApps model of naming things, but synApps is a bit special in this regard.
The more common pattern is to have <module> export <module>.dbd for inclusion by applications, and I would lean towards proposing synApps make a step in that direction.
What is "its own use" for a support module anyway? By definition, a support module provides a library and resource files (like dbd files and db templates) that go with it. Tests and examples should rather be moved into embedded self-contained TOP structures - 3.15 provides convenient Makefile rules to do that. This has multiple advantages: it clearly separates support module and example code (inexperienced users usually can't tell which is which in the existing mixed modules, and create worse applications as a result), and it allows simply copying out the complete embedded example tree into their own work area (requiring only a change in the configure/RELEASE file to locally build a correct full example app).
Just my 2.5ct... ~Ralph