| 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 2025 | 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 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: using areaDetector as a support library only |
| From: | "Ernest L. Williams Jr." <[email protected]> |
| To: | "Ernest L. Williams Jr." <[email protected]> |
| Cc: | EPICS Techtalk <[email protected]> |
| Date: | 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