Experimental Physics and
Industrial Control System

"Mooney, Tim M." <[email protected]> · Wed, 3 Dec 2014 18:43:11 +0000

Yeah, I worded that really badly.  It's not asyn that's a problem, but the fact that lots of 3.14 modules included asyn.dbd where it's no longer ok in 3.15.  What I should have said is to look for "asyn.dbd" when you're modifying modules to work with 3.15.

Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

________________________________________
From: Mark Rivers [[email protected]]
Sent: Wednesday, December 03, 2014 12:16 PM
To: Mooney, Tim M.; [email protected]; Dudley, David; [email protected]
Subject: RE: FW: EPICS 3.15.1

> 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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System