Hi Mark,
I think, my email made you more confusions. I know now, this is not
what you want.
Anyway, I can answer your question about this email about a tool.
That tool is src/tools/assembleSnippets.pl in epics base, works
within the EPICS building rule such as configure/RULES_EXPAND
Best,
Han
On 11/4/19 4:45 PM, Mark Rivers wrote:
Hi Han,
The release notes say this:
“A tool has been added that assembles file snippets specified on the command line into a single output file, with sorting and replacing/adding of snippets done based on their file names.”
I find this unclear. What command line is being referred to here? Is this a Linux/Windows shell command or an iocsh command, i.e. is the tool used at build time or at run time? If it is an iocsh run-time command then it might solve my problem.
The release notes also do not give the name of the tool.
Thanks,
Mark
Sent from my iPhone
On Nov 4, 2019, at 9:37 AM, Jeong Han Lee <[email protected]> wrote:
Hi Mark,
The following Release note may help you to find a proper solution.
https://epics.anl.gov/base/R3-15/3-docs/RELEASE_NOTES.html
Assembling files from numbered snippets
A tool has been added that assembles file snippets specified on the command line into a single output file, with sorting and replacing/adding of snippets done based on their file names. The build system integration requires the output file to be specified setting COMMON_ASSEMBLIES (arch independent) or ASSEMBLIES (created by arch), then defining the snippets for each assembly setting *_SNIPPETS (explicitly) or *_PATTERN (searched relative to all source directories).
I actually didn't do anything on my side, since ESS uses its own way to combine dbd files. I just have learned from Ralph's code there is a way to combine dbd by using the new rules. Sorry for useless replies.
HTH,
Han
On 11/4/19 4:14 PM, Mark Rivers wrote:
I have not used snippets, so I may be wrong about this.
But since this is a Makefile rule it looks to me like this just affects building the dbd file, not what happens at runtime when the dbd file is loaded.
Building the dbd file is not the problem, I am building the dbd file appropriately on each arch if there is not already a dbd file. The problem is that there is just a single dbd file, which is appropriate for some arch’s but not others.
Mark
Sent from my iPhone
On Nov 4, 2019, at 1:54 AM, Jeong Han Lee <[email protected]> wrote:
Hi Mark,
The dbd_SNIPPETS rule may be what you are looking for. For example,
https://github.com/ralphlange/opcua/blob/master/devOpcuaSup/Makefile#L40
Best,
Han
On 11/2/19 8:36 PM, Mark Rivers via Core-talk wrote:
One of the nice things about EPICS is the ability to build multiple architectures in the same tree. This works well for libraries since arch is kept in its own directory.
However, it seems to have problems with dbd files.
Consider a complex application like ADSimDetector. I want to build that application on 32/64 bit Linux, 32/64 bit Windows, MacOS, vxWorks, etc. However, there are a number of features that are available on some architectures, but not all. For example GraphicsMagick and OpenCV don’t build on vxWorks, I might have OpenCV for Linux but not for Windows, etc. The problem is that there is only one version of simDetectorApp.dbd. Whichever architecture is built first creates that dbd file, and it may not be compatible with other architectures that are built later.
The solution that I have seen recommended, and have used in some cases, is to use a different dbd file name for each architecture. For example, the main application I run on our beamlines, CARS, the dbd directory contains this:
corvette:~/support/CARS>ls -l dbd
total 3928
-r--r--r-- 1 epics domain users 971697 Oct 14 14:52 CARSLinux.dbd
-r--r--r-- 1 epics domain users 974335 May 17 08:31 CARSLinuxNoLibUsb.dbd
-r--r--r-- 1 epics domain users 1057936 May 15 18:08 CARSVX.dbd
-rwxrwxr-x 1 epics domain users 1010893 Oct 14 15:06 CARSWin32.dbd
So I had to use different names for Linux, Linux without libusb (old SUSE on Pilatus), vxWorks, and Windows. If there are some feature I wanted to use on 64-bit Windows that was not available on 32-bit Windows I would need to create yet another dbd file name.
This seems silly. It seems like the right solution is to simply make dbd files be architecture-dependent, rather than a single version in O.Common.
Is this already supported somehow, or is it planned for some time in the future?
Thanks,
Mark
- References:
- Architecture dependent dbd files Mark Rivers via Core-talk
- Re: Architecture dependent dbd files Mark Rivers via Core-talk
- Re: Architecture dependent dbd files Jeong Han Lee via Core-talk
- Re: Architecture dependent dbd files Mark Rivers via Core-talk
- Navigate by Date:
- Prev:
Re: Architecture dependent dbd files Mark Rivers via Core-talk
- Next:
Re: Base 7 modules/RELEASE*.local files Mark Rivers via Core-talk
- 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:
Re: Architecture dependent dbd files Mark Rivers via Core-talk
- Next:
Re: Architecture dependent dbd files Johnson, Andrew N. via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
|