Architecture dependent dbd files

[Mark Rivers via Core-talk <core-talk@aps.anl.gov>]

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