Experimental Physics and
| |||||||||||||||||
|
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
| ||||||||||||||||
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |