Have to agree with Ralph on that point.
Support modules may build (and probably -should- build) test programs to insure they operate correctly, but I don't see why those should be built as a part of the library. Separating the library from the test program would seem to make sense to me, as the process to create the actual test program now becomes exactly the same as the process used to create an IOC using that module.
Seems a better way to separate functions, to me.
I'll add 0.5ct to Ralphs suggestion....
David Dudley
Controls Engineer III
Facility for Rare Isotope Beams
Michigan State University
640 South Shaw Lane
East Lansing, MI 48824, USA
Tel. 517-908-7133
Email: [email protected]
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ralph Lange
Sent: Wednesday, December 03, 2014 10:59 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 Mark Rivers
- 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.
- Navigate by Date:
- Prev:
Re: Using EPICS with Attocube stepper motor Ana Malagon
- Next:
Create two channels on same PV name in same CA context? J. Lewis Muir
- 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 Mooney, Tim M.
- Next:
RE: FW: EPICS 3.15.1 Mark Rivers
- 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
|