g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: Re: Revision numbers
From: Ralph Lange <Ralph.Lange@bessy.de>
To: Andrew Johnson <anj@aps.anl.gov>
Cc: EPICS Core-Talk <core-talk@aps.anl.gov>, Janet Anderson <jba@aps.anl.gov>
Date: Fri, 20 Jan 2006 12:58:41 +0100
Hi Andrew,
[...]
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.
Alas, that doesn't work, as $(CONFIG)/CONFIG says
#  Base-specific build options
#
include $(CONFIG)/CONFIG_BASE
include $(CONFIG)/CONFIG_BASE_VERSION

#  Site-specific build options
#
include $(CONFIG)/CONFIG_SITE
i.e. EPICS_SITE_VERSION is used (within $(CONFIG)/CONFIG_BASE_VERSION) before it is set (in $(CONFIG)/CONFIG_SITE). Bummer!
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?
Would be, if it worked.
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.
Well, I see what you mean, but I don't really like the idea too much:
Formal argument: the path I'd have to add is not really an external product to base, which is what the RELEASE file is for.
Practical argument: I don't like the idea that I would have to manually create lib install directories before the build, i.e. building base from scratch or after "make uninstall" would never generate complete and correct binaries. Yuck, yuck.
  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.
It would differ frome case to case, I guess. Usually, support modules would point their base to the generic path, but while testing a support module, I would still have to have the ability to configure explicitly which base libraries will be used at runtime.
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 don't thinks it's really cleaner - see above.

What should we do with the include order in $(CONFIG)/CONFIG? Doing the site-specific include first doesn't sound right, either. Maybe the order should be:
CONFIG_BASE, CONFIG_SITE, CONFIG_BASE_VERSION?
Or should we move the EPICS_SITE_VSTRING definition and its surrounding ifdef into CONFIG_SITE? Yuck.
Create another file (CONFIG_BASE_SUMUP?) that contains definitions that use things which might get overridden in CONFIG_SITE, and is included between site-specifics and host arch specifics? Better, maybe.

What do you think?

Ralph


Replies:
Re: Revision numbers Andrew Johnson

Navigate by Date:
Prev: R3.14.8.2 Andrew Johnson
Next: 3.14.8 / cygwin dependency Ralph Lange
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014 
Navigate by Thread:
Prev: R3.14.8.2 Andrew Johnson
Next: Re: Revision numbers Andrew Johnson
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·