RE: INSTALLING IOC Applications

["Rees, NP \(Nick\)" <nick.rees@diamond.ac.uk>]

Ernest,

What we do at DLS (and what I used to do in Hawaii) is to install boot
scripts in <TOP>/bin/<target arch>.

We preprocess the boot scripts (i.e. the *.cmd files) to do target
architecture specific macro substitution (to form *.boot files). So
instead of the cdCommands and envPaths files we do it all through macro
substitution in the st.cmd file. For example, the makeBaseApp.pl st.cmd
file for the application <fred> looks like this:

#!$(INSTALL)/bin/$(ARCH)/fred

## You may have to change fred to something else
## everywhere it appears in this file

cd "$(INSTALL)"

# Load binaries on architectures that need to do so.
# VXWORKS_ONLY, LINUX_ONLY and RTEMS_ONLY are macros that resolve
# to a comment symbol on architectures that are not the current
# build architecture, so they can be used liberally to do architecture
# specific things. Alternatively, you can include an architecture
# specific command file.
$(VXWORKS_ONLY)ld < bin/$(ARCH)/fred.munch

## This drvTS initializer is needed if the IOC has a hardware event
system
#TSinit

## Register all support components
dbLoadDatabase("dbd/fred.dbd")
fred_registerRecordDeviceDriver(pdbbase)

## Load record instances
#dbLoadRecords("db/<filename>.db","<List of macros, e.g. user=xxx>")

## Set this to see messages from mySub
#mySubDebug 1

iocInit()

## Start any sequence programs
#seq sncExample,"user=xxx"

Note that, once built, this runs on all VxWorks architectures and Linux
- I don't know about RTEMS, since we don't have it here (but I must
admit that the $(VXWORKS_ONLY) macro is a bit kludgy and would welcome
better suggestions). The macro substitution idea isn't mine, it dates
from an ages old LANL application environment (but I think that used to
use colons to separate the macros - it was before we all decided to use
$() ).

Note we do this all via site wide CONFIG.Dls and RULES.Dls files and so
this gets rid of another pet hate of mine - the special inclusion of
RULES.ioc file in startup directories so the build rules are different -
all Makefiles just include one RULES file and so have access to the same
set of make rules.

I can send our special RULES.Dls and CONFIG.Dls to you if you want. We
also find we need another installation directory called (we call is
data), and a DATA make target for architecture independent
configurations (such as edm screens, protocol files, archiver
configuration, alarm configuration, motor controller programs etc).

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713 

> -----Original Message-----
> From: Ernest L. Williams Jr. [mailto:ernesto@ornl.gov] 
> Sent: 07 May 2007 22:56
> To: tech-talk@aps.anl.gov
> Cc: ernesto@ornl.gov; ernesto@slac.stanford.edu
> Subject: INSTALLING IOC Applications
> 
> Hi,
> 
> In order to take full advantage of "INSTALL_LOCATION_APP", we need to
> install the products from iocBoot as well.  Has anyone else 
> address this
> issue at their site?
> 
> 
> Proposal:
> 
> ============================
> Before doing a make:
> 
> <TOP>
>   --configure
>   -- <yourAppName>App
>   -- <iocBoot>
> ============================
> 
> ============================
> After doing a make:
> 
> <TOP>
>   --configure
>   -- <yourAppName>App
>   -- <iocBoot>
>   -- bin
>   -- db
>   -- dbd
>   -- include
>   -- lib
>   -- iocStartup
>      -- ioc<yourIOCName>
>         -- st.cmd
>         -- cdCommands
>         -- envPath
> ============================
> 
> Notice, now that there is a new product directory called "iocStartup"
> 
> Of course, now the RULE could be changed to move "iocStartup" 
> along with
> bin, db, dbd, include, lib to the desired installation tree.
> 
> Looks like clean and uninstall will work just fine as well.
> 
> 
> 
> 
> Thanks,
> Ernest 
> 
> 
> 
>