1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 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 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: using areaDetector as a support library only |
From: | "Ernest L. Williams Jr." <[email protected]> |
To: | Mark Rivers <[email protected]> |
Cc: | Tech Talk <[email protected]> |
Date: | Fri, 18 May 2012 13:55:01 -0700 |
On 05/18/2012 01:00 PM, Mark Rivers wrote:
areaDetector is rather different from motor. The motor application (WithAsyn) is almost always used as only a test application, since one generally does not have a very useful IOC if all it does is run motors. The areaDetector applications on the other hand are what a majority of users actually run. They typically don't integrate areaDetector into a larger application. They run a soft IOC that just controls a single detector. In fact I think most areaDetector users just use the pre-built binaries that I produce, they don't even build it at all. They certainly can integrate it into a larger application, and some sites do, but it is not typical.
We intend to run multiple detectors in one IOC application process.In our systems we installed a PCI-based timing hardware (MicroResearch Event Receiver).
A single IOC then will control the EVR and multiple detectors.
For that reason I don't think one test app for all detectors is a good idea, because it will become huge, and generally people want an application for a specific detector. I think we should stick with building one application per detector. But it would be nice to be able to isolate the application (which has lots of module dependencies) from the library (which has few dependencies). It seems to me that either means 2 separate configure/RELEASE files, or commenting out the extra module lines when only building the library and not the application.
I vote for commenting out the sections that build example applications.
If anyone has better ideas please share them! Thanks, Mark -----Original Message----- From: Bruce Hill [mailto:[email protected]] Sent: Tuesday, May 15, 2012 11:20 PM To: Mark Rivers Cc: Williams Jr., Ernest L.; Tech Talk Subject: Re: using areaDetector as a support library only 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 [[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