I agree with a lot of this.
> 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.
I've come to agree with this, mostly because people's first guess seems often enough to be that "module.dbd" is what they should include. However, it's not the sort of change you can creep up on, as far as I can tell; you either go there or you don't, and I'm wary of causing configuration trouble for users who want to upgrade existing applications.
> Tests and examples should rather be moved into embedded self-contained TOP structures - 3.15 provides
> convenient Makefile rules to do that.
That sounds pretty good. I'll look into it.
Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab
________________________________________
From: [email protected] [[email protected]] on behalf of Ralph Lange [[email protected]]
Sent: Wednesday, December 03, 2014 9:58 AM
To: EPICS Tech-Talk
Subject: Re: FW: EPICS 3.15.1
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
- Replies:
- Re: FW: EPICS 3.15.1 Ralph Lange
- References:
- EPICS 3.15.1 Dudley, David
- FW: EPICS 3.15.1 Dudley, David
- RE: FW: EPICS 3.15.1 Dudley, David
- Re: FW: EPICS 3.15.1 Michael Davidsaver
- RE: FW: EPICS 3.15.1 Mooney, Tim M.
- Re: FW: EPICS 3.15.1 Ralph Lange
- Navigate by Date:
- Prev:
RE: Area Detector and Andor Mark Rivers
- Next:
Re: Area Detector and Andor Zenon Szalata
- 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
- Navigate by Thread:
- Prev:
Re: FW: EPICS 3.15.1 Ralph Lange
- Next:
Re: FW: EPICS 3.15.1 Ralph Lange
- 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
|