Experimental Physics and
Industrial Control System

Mark Rivers via Core-talk <[email protected]> · Tue, 5 Nov 2019 13:10:51 +0000

Hi Andrew,

Ø  Can you summarize the differences between the content of those DBD files? Is it just device(), driver(), registrar(), function() and variable() entries that need to be added/removed, and what are the various different conditions you would need to be able to use to enable/disable those entries?

Yes, it is device(), driver(), registrar(), function() and variable() entries that are different.

To understand the conditions you can look at the Makefile for synApps xxx module:

https://github.com/epics-modules/xxx/blob/master/xxxApp/src/Makefile

That is a single application that is built to run on many architectures.  It uses different dbd file names for each architecture, and conditionally adds different dbd files and libraries.  This "works" but is a pain: a single startup script cannot be used because a different dbd file is needed for each ARCH, and it is not currently distinguishing between 32/64 bit versions of Windows or Linux, or various versions of Linux where some packages may not be available.  These could obviously be added, but I am looking for a cleaner solution.

areaDetector's commonDriverMakefile is another example.

https://github.com/areaDetector/ADCore/blob/master/ADApp/commonDriverMakefile

Depending on the contents of CONFIG_SITE.local.$(EPICS_HOST_ARCH) things like WITH_BLOSC, ADPLUGINBAR, and ADCOMPVISION may be defined on one architecture and not on others.  This is because the Blosc or OpenCV libraries are not available on some architectures.

> I would much prefer to build conditionals into the DBD file than to support multiple architecture-specific DBD files (see below for why); I think I can see a relatively straight-forward way to do that, although this would obviously only work on new EPICS releases.

That would be fine as well.

Thanks,

Mark

From: Core-talk <[email protected]> On Behalf Of Johnson, Andrew N. via Core-talk
Sent: Monday, November 4, 2019 3:45 PM
To: [email protected]
Subject: Re: Architecture dependent dbd files

Hi Mark,

On 11/2/19 2: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.

...

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.

Can you summarize the differences between the content of those DBD files? Is it just device(), driver(), registrar(), function() and variable() entries that need to be added/removed, and what are the various different conditions you would need to be able to use to enable/disable those entries?

I would much prefer to build conditionals into the DBD file than to support multiple architecture-specific DBD files (see below for why); I think I can see a relatively straight-forward way to do that, although this would obviously only work on new EPICS releases.

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.

If each target <arch> has its own set of dbd files, it would need its own copies of the generated *Record.h and menu*.h include files to match, and we would have to add new dbd/<arch> and include/arch/<arch> install directories to put them in. The build system would get a bit more complicated to support these, and builds will take a bit longer as each architecture built will have to run the conversion scripts (currently they only get run once, by the first host architecture).

- Andrew

--

Complexity comes for free, Simplicity you have to work for.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System