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
>
>
- References:
- Re: Multiple target os-class application build Andrew Johnson
- Navigate by Date:
- Prev:
Re: Minor VLinac compilation problem on OS X 10.5? Eric Norum
- Next:
RE: TTL output with soft IOC on Linux 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
- Navigate by Thread:
- Prev:
Re: Multiple target os-class application build Andrew Johnson
- Next:
Re: Multiple target os-class application build Sue Witherspoon
- 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
|