Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 15 Dec 2005 17:59:05 -0600

Ernest L. Williams Jr. wrote:

There is already a patch listed in the "Known Problems" section for the
R3.14.8 release. Does the patch make it R3.14.8.1 or is there more?

There are also some Win32 changes to do with exported symbols that are

needed for Asyn.

Well, I think that a 4th revision number is okay to describe a patch.

What does each number represent in your current definition of the
Revision numbering scheme?

From the current configure/CONFIG_BASE_VERSION:

EPICS_VERSION=3
EPICS_REVISION=14
EPICS_MODIFICATION=8
EPICS_UPDATE_NAME=
EPICS_UPDATE_LEVEL=0

The variable names are not particularly meaningful, and the two UPDATE

items may be about to be replaced with something else.

EPICS_VERSION used to mean the version of the CA protocol; different

versions were not expected to be able to talk to each other.

EPICS_REVISION increases indicates a significant change in features

and/or functionality, and may require significant effort to upgrade IOCS

and/or support applications (3.13 to 3.14). EPICS_MODIFICATION

increments indicate minor enhancements to features and APIs, and

incorporation of bug fixes.

EPICS_UPDATE_NAME were originally designed for the words 'alpha'/'beta'

and EPICS_UPDATE_LEVEL for the alpha/beta version number. We'd like to

replace these two with a new EPICS_PATCH_LEVEL variable, and add a

variable EPICS_CVS_SNAPSHOT that distinguishes between official releases

and CVS snapshots. Between official releases, the version numbers would

look like 3.14.8-CVS.

We're also adding an EPICS_SITE_VERSION string in configure/CONFIG_SITE

that allows sites to easily append their own version information to the

EPICS version string - if set this will be appended after the -CVS.

This is most of the new CONFIG_BASE_VERSION file:

EPICS_VERSION = 3
EPICS_REVISION = 14

# This part may contain letters, eg 0beta1
EPICS_MODIFICATION = 8

# Not included if zero
EPICS_PATCH_LEVEL = 0

# This must be -CVS or (during an official release) blank
EPICS_CVS_SNAPSHOT=-CVS

# No changes should be needed below here

ifneq ($(EPICS_PATCH_LEVEL),0)
  EPICS_PATCH_VSTRING=.$(EPICS_PATCH_LEVEL)
endif

ifneq ($(strip $(EPICS_SITE_VERSION)),)
  EPICS_SITE_VSTRING=-$(EPICS_SITE_VERSION)
endif

EPICS_SHORT_VERSION=$(EPICS_VERSION).$(EPICS_REVISION).$(EPICS_MODIFICATION)$(EPICS_PATCH_VSTRING)
EPICS_VERSION_NUMBER=$(EPICS_SHORT_VERSION)$(EPICS_CVS_SNAPSHOT)$(EPICS_SITE_VSTRING)
EPICS_VERSION_STRING="EPICS Version $(EPICS_VERSION_NUMBER)"

Ralph:

Your local definitions for UPDATE_NAME and UPDATE_LEVEL would be

combined into EPICS_SITE_VERSION in the CONFIG_SITE file. Is the above

likely to be sufficient for BESSY's needs? Thanks for pointing out the

additional uses of those var's BTW.

Looking at the HPUX addition to SHRLIB_SEARCH_FULLPATHDIRS in the

os/CONFIG_SITE.Common.hpux-parisc file, I think you could do this an

easier way: If you add an entry to your base/configure/RELEASE file

pointing to the /opt/... install location top, and ensure that there is

actually a lib/hpux-parisc directory present before you build base, then

that lib directory will get added to SHRLIB_SEARCH_DIRS inside base's

auto-generated CONFIG_APP_INCLUDE file. I'm not sure whether you'd need

that RELEASE file entry just in base, or in your support modules too -

that depends whether the definition of EPICS_BASE in the support modules

points to the development location or to the /opt/... install directory.

 Overall I suspect this would be a cleaner way to get your install

directory into the runtime search path as it puts the site-specific path

into the RELEASE file.

I've just committed this change to CVS but haven't touched the hpux

stuff, if you have time please have a look and work out how you want to

play this.

Thanks,

- Andrew
--
* * Matt Santos / / Leo McGarry * * For a Brighter America * *

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System