EPICS Home

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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: using areaDetector as a support library only
From: "Williams Jr., Ernest L." <[email protected]>
To: Mark Rivers <[email protected]>
Cc: Tech Talk <[email protected]>
Date: Tue, 15 May 2012 20:03:57 -0700

Sent from my iPhone

On May 15, 2012, at 7:59 PM, "Mark Rivers" <[email protected]> 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.
Yes, but we are used to doing that when we release modules for production 
That is what we currently do with the iocAdmin package from Stephanie Allison and Ralph Lange

Cheers
Ernest

> 
> Mark
> 
> ________________________________________
> From: Bruce Hill [[email protected]]
> 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:[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
> 


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 Mark Rivers
Next: Re: using areaDetector as a support library only Bruce Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: using areaDetector as a support library only Mark Rivers
Next: Re: using areaDetector as a support library only Bruce Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024