Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Wed, 27 Feb 2008 13:18:41 -0600

I'd really like to see this changed in a future release, so that DBD
files are put in an architecture-specific directory, and have them
accept statements that allow lines to be included/excluded for specific
architectures.

The scheme one has to use now is a real pain, particularly when building
complex applications that use multiple modules.  If module A has
architecture-specific DBD files, then module B that depends on it needs
to know that.  B needs to be modified if A is modified to add a new
architecture, etc.

Mark

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Andrew Johnson
> Sent: Monday, February 25, 2008 2:56 PM
> To: Sue Witherspoon
> Cc: [email protected]
> Subject: Re: Multiple target os-class application build
> 
> Hi Sue,
> 
> >     I sent this question thru tech-talk while tech-talk 
> 'seemed to be 
> > down'. The question did come up two days later but I got no 
> response 
> > at 
> > all.
> 
> We had a mailman outage last week which delayed a whole lot 
> of messages after a python upgrade on our webserver; I hope 
> it's all fixed now.
> 
> >    I have an application that will run on a vxWorks ioc and 
> an RTEMS 
> > ioc.  Obviously, there are some functions that are peculiar to 
> > vxWorks. 
> > The Makefile Definitions allow for this by using 
> <app>_SRCS_<osclass>  
> > 
> > or vxWorksOnly_SRCS etc.  But is there a
> > tag or definition for the DBD files that would 
> differentiate between 
> > vxWorks and  RTEMS? 
> > I'm using Epics 3.14.8.2.
> 
> DBD files are universal, meaning that we don't create a 
> separate expanded DBD file for each target architecture we're 
> building for; in fact they get expanded inside the O.Common 
> directory which all arch's use.  If you have some DBD entries 
> that are specific to a particular architecture, you've going 
> to have to create a seperate expanded DBD file for that arch. 
>  However this isn't generally as hard as it might seem, since 
> you can use variable substitutions in the Makefile to create 
> the various different versions without duplicating 
> everything.  Here's an example snippet, untested though since 
> I'm at home right now:
> 
> 
> PROD_IOC = app
> 
> DBD += unix.dbd rtems.dbd vxworks.dbd
> 
> common_DBD += base.dbd
> common_DBD += allArchs.dbd
> 
> unix_DBD += $(common_DBD)
> unix_DBD += unixOnly.dbd
> 
> rtems_DBD += $(common_DBD)
> rtems_DBD += rtemsOnly.dbd
> 
> vxworks_DBD += $(common_DBD)
> vxworks_DBD += vxworksOnly.dbd
> 
> # <name>_registerRecordDeviceDriver.cpp is created from <name>.dbd
> app_SRCS_DEFAULT += unix_registerRecordDeviceDriver.cpp
> app_SRCS_RTEMS += rtems_registerRecordDeviceDriver.cpp
> app_SRCS_vxWorks += vxworks_registerRecordDeviceDriver.cpp
> 
> app_SRCS_DEFAULT += appMain.cpp
> app_LIBS += $(EPICS_BASE_IOC_LIBS)
> 
> 
> HTH,
> 
> - Andrew
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System