2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Revision numbers |
From: | Ralph Lange <[email protected]> |
To: | Andrew Johnson <[email protected]> |
Cc: | EPICS Core-Talk <[email protected]>, Janet Anderson <[email protected]> |
Date: | Fri, 20 Jan 2006 12:58:41 +0100 |
Hi Andrew,[...]Alas, that doesn't work, as $(CONFIG)/CONFIG says # Base-specific build optionsi.e. EPICS_SITE_VERSION is used (within $(CONFIG)/CONFIG_BASE_VERSION) before it is set (in $(CONFIG)/CONFIG_SITE). Bummer! Ralph: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 |