Experimental Physics and
Industrial Control System

"Ernest L. Williams Jr." <[email protected]> · Fri, 18 May 2012 13:57:27 -0700

Hi,

Just making sure that tech-talk is also added here as well :)

On 05/18/2012 01:49 PM, Ernest L. Williams Jr. wrote:

On 05/18/2012 01:34 PM, Bruce Hill wrote:

Hi Mark,
I think it stems from differences in how we manage our releases.
For my release model, and I suspect Ernest's as well, I maintain
separate release paths for areaDetector R1.6 compiled against
base 3.14.9, 3.14.11, and 3.14.12.    Thus, my configure/RELEASE
file would use R1.6.0-0.4.0 for areaDetector compiled against 3.14.11
and R1.6.0-0.5.0 for areaDetector compiled against 3.14.12.

We no longer do that.
We make sure all modules build against any RELEASE of EPICS.

The problem comes when an IOC application wants to try Ben Franksen's
new sequencer but the areaDetector is using another version.
This is the kind of thing that cause a module version dependency chain
reaction.
The IOC application only wants to use the areaDetector as a library and
maybe database templates.
This is why we reduce the dependencies of modules to minimize the
version conflict for IOC Apps.

I'm sure each site has their own way or solving this problem, but
in general it's worked well for us as we need to continue to support
IOC's running against older versions of base until such time as
someone can verify that the IOC builds w/ a new base and more
importantly, gets enough access to the device to be able to test
if the new build works.

The down side for modules which depend on other modules, which
themselves depend on other modules, is that a script to automate
updating all the configure release files and build each module in
the proper order would be complicated to write and maintain.

Regards,
- Bruce

On 5/18/2012 12:48 PM, Mark Rivers wrote:

I call it the module dependency problem, and when I update base,
it causes me to have to release new module versions in 4 different
sets, depending on how many layers of module dependency they have.

I don't quite understand that.  We don't release new versions of modules when we upgrade base, etc.  We just run "make release" which automatically updates all of the module configure/RELEASE files to point to the new version of base.  Of course those modules have to be known to work with the new release of base.

I agree that it's good to minimize module dependencies, and if only the example application needs other modules that should be isolated somehow.  The only clean way to isolate it is to put it in another module as far as I know.

areaDetector is a bit unique in this regard.  I believe the large majority of areaDetector users do not use the applications as "examples", but rather that is the final application that they run.  They copy the application to their marCCD Linux machine, or Pilatus Linux machine and run it there.  They don't integrate it into a larger application, though of course they could, and sophisticated sites like SLAC and Diamond certainly do.

Mark

-----Original Message-----
From: Bruce Hill [mailto:[email protected]]
Sent: Wednesday, May 16, 2012 1:14 AM
To: Mark Rivers
Cc: Williams Jr., Ernest L.
Subject: Re: using areaDetector as a support library only

Hey Mark, I see where Ernest's coming from now.
I like using the consistency checking, but it is a problem
when module's have unnecessary dependencies,
as we then have to create new releases for areaDetector
when we wouldn't otherwise need to.

I call it the module dependency problem, and when I update base,
it causes me to have to release new module versions in 4 different
sets, depending on how many layers of module dependency they have.

It seems to me that I've seen an example somewhere of a
test app being built with it's own configure/RELEASE file one
level down from $TOP.     I'll let you guys know if I find it.

Regards,
- Bruce

On 5/15/2012 8:01 PM, Williams Jr., Ernest L. wrote:

Hi Bruce,
The problem arises when the EPICS make system does consistency checks of the configure/RELEASE files
An IOC App should not have to be locked to a specific version of autosave when using the areaDetector module

If the areaDetector separates the library  app from the IOC test app then that would do the trick :)

Cheers
Ernest

Sent from my iPhone

On May 15, 2012, at 7:43 PM, "Hill, Bruce"<[email protected]>     wrote:

Hi Ernest,
I'm not clear on why autosave, calc, busy, and sscan are
causing a problem for you.   They only appear to be needed
by the areaDetector test apps.   We build areaDetector as a
module, then link it into an IOC just like our other modules.

I haven't tried building it into an IOC that didn't use autosave,
calc, etc, so there may be an issue there.    If so, it looks
like the problem would be prosilicaApp.dbd, which not only
has the areaDetector stuff like "registrar(NDStdArraysRegister),
but also has autosave, calc, busy, etc.     I think that could
be solved by moving all the areaDetector specific dbd lines into
prosilicaSupport.dbd,

One could also comment out the PROD_ lines in the areaDetector
makefiles to avoid building the apps, but reworking the dbd
files may still be needed so you can build without the extra modules.

Regards,
- Bruce

On 05/15/2012 02:54 PM, Mark Rivers wrote:

Hi Ernest,

The next release of areaDetector will be R1-8.  It will keep the same structure as the current release, and should be out soon.  I am making the final tweaks to a driver for the Photonic Sciences Limited detectors.

For the release after that I will break areaDetector into multiple modules.

areaDetector will contain only the code for ADSrc and pluginSrc.  It will not depend on any other EPICS modules besides base and asyn.

Each detector will be in its own module, e.g. ADProsilica or something like that.  My plan was to make ADProsilica build both the library and the example application.  That means its configure/RELEASE would depend on synApps modules like what you show.  You still might not like that, since you would want the ADProsilica module to also be just a library that you can build into your IOC.

I could break each detector into 2 modules:
ADProsilicaLib - just builds a library, does not depend on any other modules except base and asyn
ADProsilicaApp - builds an example application, depends on other synApps modules

The problem with that is that areaDetector would then be broken into 29 modules, since there are currently 14 detectors plus the base code.  That's a lot more work for me, since each needs to be separately packaged and released.  But maybe it's the best way to do it.

I'm also sending this to tech-talk, since I know others have expressed similar desires, and I'd like to get comments.

Mark

From: Ernest L. Williams Jr. [mailto:[email protected]]
Sent: Tuesday, May 15, 2012 4:32 PM
To: Mark Rivers
Cc: Williams Jr., Ernest L.
Subject: using areaDetector as a support library only

Hi Mark,

In an effort to reduce dependencies when preparing a shared module such as areaDetector; how to do this?

Here is what we have now:
SNCSEQ=$(EPICS_MODULES)/seq/$(SEQ_MODULE_VERSION)
AUTOSAVE=$(EPICS_MODULES)/autosave/$(AUTOSAVE_MODULE_VERSION)
ASYN=$(EPICS_MODULES)/asyn/$(ASYN_MODULE_VERSION)
SSCAN=$(EPICS_MODULES)/sscan/$(SSCAN_MODULE_VERSION)
CALC=$(EPICS_MODULES)/calc/$(CALC_MODULE_VERSION)
BUSY=$(EPICS_MODULES)/busy/$(BUSY_MODULE_VERSION)
STD=$(EPICS_MODULES)/std/$(STD_MODULE_VERSION)
MCA=$(EPICS_MODULES)/mca/$(MCA_MODULE_VERSION)

I would like to build areaDetector as a support library that is referenced and linked in by an
IOC application.

This means that I would like to select not to build the IOC parts of areaDetector as they depend on such as autosave.
What is the best way to achieve this?
Seems that every driver creates an App via  "ADApp/commonDriverMakefile"

I only want to include those components necessary for the module library.
We will include the other components along with our IOC Application.
What is the cleanest way to do this?

Cheers,
Ernest

--
Bruce Hill
Member Technical Staff
SLAC National Accelerator Lab
2575 Sand Hill Road M/S 10
Menlo Park, CA  94025

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System