Experimental Physics and Industrial Control System
> asyn is a problem, because asyn.dbd includes asynRecord.dbd.
> This means modules mustn't include asyn.dbd in their <module>Support.dbd files,
> else several modules will in effect be claiming to provide asynRecord.dbd.
asyn.dbd should be treated as if it were named asynSupport.dbd, which does not exist. asyn.dbd is not analogous to as.dbd, it is analogous to asSupport.dbd.
A module should never include anything in its <module>Support.dbd file that it is importing, only things that it is exporting. Thus no other yyySupport.dbd should ever include asyn.dbd, just as no other yyySupport.dbd should ever include calcSupport.dbd. If it does then the calc records will be multiply defined.
Am I missing something?
Mark
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Mooney, Tim M.
Sent: Wednesday, December 03, 2014 9:44 AM
To: [email protected]; Dudley, David; [email protected]
Subject: RE: FW: EPICS 3.15.1
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.
If you include calcSupport.dbd, you shouldn't include any <record>.dbd files that are included by calcSupport.dbd.
The strategy I've been using for 3.15 is that no module should have record types in the .dbd file it exports that are actually provided by base or some other module. Some synApps modules needed to be modified to do this, and not all of the new modules have been released, though nearly all have been tagged.
asyn is a problem, because asyn.dbd includes asynRecord.dbd. This means modules mustn't include asyn.dbd in their <module>Support.dbd files, else several modules will in effect be claiming to provide asynRecord.dbd.
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 Michael Davidsaver [[email protected]]
Sent: Wednesday, December 03, 2014 8:39 AM
To: Dudley, David; [email protected]
Subject: Re: FW: EPICS 3.15.1
On 12/03/2014 09:34 AM, Dudley, David wrote:
> Thanks for the suggestion. The as.dbd file may have been a contributing problem, but not the 'only' one, in any case.
It's still there (see below).
> So, from your comment, it sounds like I'm going to have to go through all the driver modules, and somehow insure that none of them include the base types in their .dbd files?
Yes.
> perl -CSD /home/dudleyd/R3.15.1/bin/linux-x86_64/dbdExpand.pl -I. -I.. -I../O.Common -I../../../dbd -I/home/dudleyd/R3.15.1/dbd -I/home/dudleyd/R3.15.1/dbd -I/home/dudleyd/R3.15.1/dbd -o BACNetApp.dbd base.dbd sscan.dbd aCalcoutRecord.dbd calcSupport.dbd sCalcoutRecord.dbd swaitRecord.dbd transformRecord.dbd plcAdmin.dbd as.dbd asSupport.dbd iocAdmin.dbd devIocStats.dbd system.dbd epics2bacnet.dbd IncSetRecord.dbd
Note that now both as.dbd and asSupport.dbd are being included.
- Replies:
- RE: FW: EPICS 3.15.1 Mooney, Tim M.
- 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: Create two channels on same PV name in same CA context? Andrew Johnson
- Next:
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 Dudley, David
- Next:
RE: FW: EPICS 3.15.1 Mooney, Tim M.
- 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