Experimental Physics and Industrial Control System
Geoff Savage wrote:
When I use a new epics release I need to go into each top area, modify
the configure/RELEASE file, do an uninstall, and then gmake. Are there
Makefile rules available to simplify this process?
There's nothing stopping you from having all of your configure/RELEASE
files doing an include from another file. Here's one solution, the
indented text is the content of the filename previously mentioned:
master/RELEASE-base:
SUPPORT=/path/to/somewhere
EPICS_BASE = $(SUPPORT)/base
master/RELEASE-ipac:
include RELEASE-base
IPAC = $(SUPPORT)/ipac
master/RELEASE-asyn:
include RELEASE-ipac
ASYN = $(SUPPORT)/asyn
master/RELEASE-directNetAsyn:
include RELEASE-asyn
DIRECTNETASYN = $(SUPPORT)/directNetAsyn
ipac/configure/RELEASE:
include /path/to/master/RELEASE-base
asyn/configure/RELEASE:
include /path/to/master/RELEASE-ipac
directNetAsyn/configure/RELEASE:
include /path/to/master/RELEASE-asyn
ioctop/configure/RELEASE:
include /path/to/master/RELEASE-directNetAsyn
Now if you change the definition of EPICS_BASE in master/RELEASE-base
you just need to run a
gnumake uninstall build
command in each top directory (in the right order of course!). This
task is of course itself automatable using a higher level Makefile if
you feel so inclined:
DIRS = base ipac asyn directNetAsyn ioctop
build: $(addsuffix .build, $(DIRS))
clean: $(addsuffix .clean, $(DIRS))
rebuild: $(addsuffix .rebuild, $(DIRS))
uninstall: $(addsuffix .uninstall, $(DIRS))
%.build:
$(MAKE) -C $(basename $@) build
%.clean:
$(MAKE) -C $(basename $@) clean
%.rebuild:
$(MAKE) -C $(basename $@) rebuild
%.uninstall:
$(MAKE) -C $(basename $@) uninstall
I suspect you might have problems if you try to simplify the process by
reducing the number of master/RELEASE-xxx files, because you don't want
earlier built trees searching for include files in the later top areas
(for example your ioctop might have its own private definition of
menuConvert.dbd which you wouldn't want other IOCs or EPICS Base to use).
Another approach would be to look at what synApps does - they have their
own build configuration system and script(s) that IIRC installs RELEASE
file updates into supporting application tops.
However I would counsel against making use of anything like this in an
operational build tree, since you can't guarantee that the new version
of some support library isn't going to break one of your applications in
a subtle way. Updates to the RELEASE file of operational top areas
should be done deliberately by the engineer responsible for that group
of IOCs.
HTH,
- Andrew
--
Not everything that can be counted counts,
and not everything that counts can be counted.
-- Albert Einstein
- References:
- build multiple tops? Geoff Savage
- Navigate by Date:
- Prev:
sequencer under linux questions Dennis Nicklaus
- Next:
Re: Moxa N-Port, ASYN and IOC Exit John William Sinclair
- 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: build multiple tops? Emmanuel Mayssat
- Next:
Moxa N-Port, ASYN and IOC Exit John Dobbins
- 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