EPICS Controls 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  2012  2013  <20142015  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  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: FW: EPICS 3.15.1
From: Mark Rivers <[email protected]>
To: "'Dudley, David'" <[email protected]>, EPICS Tech-Talk <[email protected]>
Date: Wed, 3 Dec 2014 19:04:41 +0000
The convention used at Diamond, which has been adopted for areaDetector (R2-0 onward) is the following, using the Andor detector as an example:

ADAndor
  configure/      Configuration files for building the library
  andorApp
    src/          Library source
    Db/           Database files
    op/
      adl/        medm files
      edl/        edm files
      ...  
  andorSupport    Vendor provided files
    os
      linux-x86   Vendor library for 32-bit Linux
      win32-x86   Vendor library for 32-bit Windows
      ...
  documentation/  Always helpful
  iocs/
    andorIOC/     Example IOC application
      configure/  Configuration file for the example IOC
      andorApp/
        src/      Source code for example application
      iocBoot/
        iocAndor/ Example IOC boot directory


ADAndor/configure/RELEASE only includes the dependencies required to build the library

ADAndor/iocs/andorIOC/configure/RELEASE includes all of the dependencies to build the example application, i.e. some synApps modules.

There is a flag in ADAndor/configure/CONFIG_SITE that controls whether the ADAndor/iocs directory gets built at all.  This allows one to build only the library, and not even have the synApps modules present.

Mark


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dudley, David
Sent: Wednesday, December 03, 2014 10:41 AM
To: EPICS Tech-Talk
Subject: RE: FW: EPICS 3.15.1

Have to agree with Ralph on that point.

Support modules may build (and probably -should- build) test programs to insure they operate correctly, but I don't see why those should be built as a part of the library.  Separating the library from the test program would seem to make sense to me, as the process to create the actual test program now becomes exactly the same as the process used to create an IOC using that module.

Seems a better way to separate functions, to me.

I'll add 0.5ct to Ralphs suggestion....

David Dudley
Controls Engineer III
Facility for Rare Isotope Beams
Michigan State University
640 South Shaw Lane
East Lansing, MI 48824, USA
Tel. 517-908-7133
Email: [email protected]





-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ralph Lange
Sent: Wednesday, December 03, 2014 10:59 AM
To: EPICS Tech-Talk
Subject: Re: FW: EPICS 3.15.1

While we're at it...

On 03/12/2014 16:44, Mooney, Tim M. wrote:
> For any synApps module, you should include <module>Support.dbd, and not <module>.dbd, because <module>.dbd is what the module builds for its own use, while <module>Support.dbd is what it builds for export to other modules.  For autosave, the names are as.dbd and asSupport.dbd.

This is indeed the synApps model of naming things, but synApps is a bit special in this regard.

The more common pattern is to have <module> export <module>.dbd for inclusion by applications, and I would lean towards proposing synApps make a step in that direction.

What is "its own use" for a support module anyway? By definition, a support module provides a library and resource files (like dbd files and db templates) that go with it. Tests and examples should rather be moved into embedded self-contained TOP structures - 3.15 provides convenient Makefile rules to do that. This has multiple advantages: it clearly separates support module and example code (inexperienced users usually can't tell which is which in the existing mixed modules, and create worse applications as a result), and it allows simply copying out the complete embedded example tree into their own work area (requiring only a change in the configure/RELEASE file to locally build a correct full example app).

Just my 2.5ct...
~Ralph




References:
EPICS 3.15.1 Dudley, David
FW: EPICS 3.15.1 Dudley, David
RE: FW: EPICS 3.15.1 Dudley, David
Re: FW: EPICS 3.15.1 Michael Davidsaver
RE: FW: EPICS 3.15.1 Mooney, Tim M.
RE: FW: EPICS 3.15.1 Dudley, David

Navigate by Date:
Prev: Re: Area Detector and Andor Zenon Szalata
Next: RE: Area Detector and Andor Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: FW: EPICS 3.15.1 Dudley, David
Next: RE: FW: EPICS 3.15.1 Dudley, David
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·