Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: using areaDetector as a support library only
From: Bruce Hill <bhill@slac.stanford.edu>
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: Tech Talk <tech-talk@aps.anl.gov>
Date: Tue, 15 May 2012 21:20:04 -0700
The source files for the apps appear to only consist of one
 *registerRecordDeviceDriver.cpp and one *Main.cpp each.
Could areaDetector be reworked to create one test app to
cover all detectors that aren't commented out in ADApp/Makefile?

That's more along the lines of what the motor module does,
and we could just comment out the build for ADApp/testApp
if we didn't want to build it.   One would still need to modify
configure/RELEASE if all the modules needed for the app weren't
available, but as Ernest noted, we're used to doing that when needed.

I suppose that would mean that if you wanted to build a test app for
only some of the detectors, you'd need to modify the PROD_LIBS
and DBD statements in the testApp/Makefile, but maybe that wouldn't
be a common need.

Actually, I'm still not clear why building an app for each detector
is a problem, so I'd be happy to see it stay as is.

- Bruce

On 05/15/2012 07:59 PM, Mark Rivers wrote:
Re splitting each detector into a lib and an app module,
I don't see the need for that.   One module can build
both the lib and a test app.   Many of our other modules
do this.
I guess the disadvantage is that there is only one configure/RELEASE file, and so one needs to edit that to comment out the other modules if one only wants to build the library.

Mark

________________________________________
From: Bruce Hill [bhill@slac.stanford.edu]
Sent: Tuesday, May 15, 2012 9:43 PM
To: Ernest L. Williams Jr.
Cc: Mark Rivers; Tech Talk
Subject: Re: using areaDetector as a support library only

Hi Mark,
I like your idea of breaking out the detector's into
separate modules, as it should make it easier for
users who only need one or two detectors.
Probably more work for you, however, so we'd be
happy continuing to just comment out the detector
directories we're not using.

Re splitting each detector into a lib and an app module,
I don't see the need for that.   One module can build
both the lib and a test app.   Many of our other modules
do this.

Regards,
- Bruce

On 05/15/2012 03:13 PM, Ernest L. Williams Jr. wrote:
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
==================================================================
What about instead; one module but two Apps?  Like so,

ADProsilica
ADProsilicaLibApp
ADProsilicaTestApp


Now, you just have one module to maintain,
When the IOC App developer is ready to use your module then we can
comment out the TestApp from the driver build.
Basically, we can follow the way the motor software is packaged.


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.
Again you can have one module with multiple Apps.
Commenting/uncommenting  in the Makefile and "configure/RELEASE"
controls the build.



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:ernesto@slac.stanford.edu]
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


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


Replies:
RE: using areaDetector as a support library only Mark Rivers
References:
RE: using areaDetector as a support library only Mark Rivers
Re: using areaDetector as a support library only Ernest L. Williams Jr.
Re: using areaDetector as a support library only Bruce Hill
RE: using areaDetector as a support library only Mark Rivers

Navigate by Date:
Prev: Re: using areaDetector as a support library only Williams Jr., Ernest L.
Next: using Makefile wildcard for installing templates, substitutions Hinko Kocevar
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: using areaDetector as a support library only Williams Jr., Ernest L.
Next: RE: using areaDetector as a support library only Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·