Re: Architecture dependent dbd files

[Jeong Han Lee via Core-talk <core-talk@aps.anl.gov>]

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 <citadel.lee@gmail.com> 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