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 2025 | 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 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Multiple target os-class application build |
From: | Sue Witherspoon <[email protected]> |
To: | Andrew Johnson <[email protected]> |
Cc: | [email protected] |
Date: | Wed, 27 Feb 2008 14:32:58 -0500 |
Thanks again for the suggestion! The following is what works for me. I have files: unix.dbd ( has base.dbd and common stuff) appInclude.dbd ( has unix.dbd ) vxworksInclude.dbd ( has unix.dbd and vxworksOnly stuff ) rtemsInclude.dbd (has unix.dbd and rtemsOnly stuff) Makefile has the following: # <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) DBD += app.db vxworks.db rtems.dbMy st.cmd for my vxworks ioc will use: # load module for <app> ld< appV/bin/mv2700/app.munch # Register all support components for <app> dbLoadDatabase ("appV/dbd/vxworks.dbd") vxworks_registerRecordDeviceDriver(pdbbase)My st.cmd for my rtems ioc will use: # load module for <app> ld< appV/bin/RTEMS-pc386/app.obj # Register all support components for <app> dbLoadDatabase ("appV/dbd/rtems.dbd") rtems_registerRecordDeviceDriver(pdbbase) Andrew Johnson wrote: 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 |