Experimental Physics and
Industrial Control System
Alas, that doesn't work, as $(CONFIG)/CONFIG says
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.
# Base-specific build options
i.e. EPICS_SITE_VERSION is used (within $(CONFIG)/CONFIG_BASE_VERSION)
before it is set (in $(CONFIG)/CONFIG_SITE). Bummer!
# Site-specific build options
Would be, if it worked.
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?
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.
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.
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
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?
- Re: Revision numbers Andrew Johnson
- Navigate by Date:
R220.127.116.11 Andrew Johnson
3.14.8 / cygwin dependency Ralph Lange
- Navigate by Thread:
R18.104.22.168 Andrew Johnson
Re: Revision numbers Andrew Johnson
ANJ, 02 Feb 2012