EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: build multiple tops?
From: Andrew Johnson <[email protected]>
To: Geoff Savage <[email protected]>
Cc: TECHTALK <[email protected]>
Date: Fri, 28 Jul 2006 14:15:05 -0500
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  <20062007  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  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024