Experimental Physics and Industrial Control System
|
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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
R3.14.8.2 Andrew Johnson
- Next:
Re: Revision numbers Andrew Johnson
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|