synApps build requirements

[rsluiter]

@anjohnson

Directory Notation:

• <synApps> refers to the directory of a generic version of synApps; e.g., synApps_5_6.
• <support> refers to the /support top level directory of the synApps directory structure
• <module> refers to the top level directory of a generic EPICS support module directory structure.
• <ioc> refers to the top level directory of an IOC's directory structure.

synApps Build Requirements

1. Running "make release" from the <support> directory will rewrite all the <module>/configure/RELEASE files specified in the <support>/configure/RELEASE file, thereby making all the support modules consistent with regard to support module versions.
2. A synApps user can “cd” to any synApps support module and build that module at any supported directory level; e.g. <module>/iocBoot/<ioc> or <module>/<module>App/src.
3. An IOC can be built based on the synApps standard support module versions specified in the <support>/configure/RELEASE file by including these lines;
   #Define the path to the synApps support directory and uncomment.
SUPPORT=/APSshare/epics/synApps_5_6/support
#Specify the standard synApps configuration.
include $(SUPPORT)/configure/RELEASE
   in the IOC’s <ioc>/configure/RELEASE file. Or, alternatively, the <support>/configure/RELEASE file can be copied to <ioc>/configure/RELEASE and customized by adding and/or omitting support modules; or, in limited cases, changing support module versions.
4. An IOC can override the standard support module versions specified in <support>/configure/RELEASE file by adding lines like the following;
   # Batchscan must be built with this version or higher
SNCSEQ=$(SUPPORT)/seq-2-1-5
   in the IOC’s <ioc>/configure/RELEASE file, typically, after the standard synApps support module versions are included. For example,
   SUPPORT=/APSshare/epics/synApps_5_6/support
include $(SUPPORT)/configure/RELEASE
SNCSEQ=$(SUPPORT)/seq-2-1-5
5. CROSS_COMPILER_TARGET_ARCHS for a synApps build is inherited from that version of EPICSbase specified by EPICS_BASE= in the <support>/configure/RELEASE file. At one time, the EPICSbase CROSS_COMPILER_TARGET_ARCHS could be overridden in the synApps build by specifying CROSS_COMPILER_TARGET_ARCHS in <support>/configure/CONFIG_SITE. That function stopped working at some point and should be restored.

synApps build implementation notes

1. The "make release" command (which was based on a Janet Anderson's perl script) is implemented in <support>/configure/makeReleaseConsistent.pl.
2. The support module build order is specified in <support>/Makefile. Support modules are grouped into tiers (currently, 6 tiers) based on their dependencies.

[rsluiter]

This has been submitted as a conversation starter; obviously, not a finished (it's never done until its' obsolete) document.

[MarkRivers]

Note that the synApps build system described above does not currently work with areaDetector. areaDetector has its own system, with a top-level configure/ directory, and uses RELEASE_xxx.local files. Running "make release" at the top-level of synApps will not correctly change the paths in areaDetector. It would be nice to find a solution to this. Currently both support/configure/RELEASE and support/areaDetector/configure/RELEASE_LIBS.local must be edited whenever a new release of asyn is installed, for example.

areaDetector/ADCore is required for a number of synApps support modules (quadEM, dxp) and will probably be use by more in the future. dxp and quadEM have a method in their RELEASE files to use the areaDetector/configure files, but it is not very elegant.

The last I checked the synApps xxx application did not build correctly if it was being built with modules that use areaDetector (dxp, quadEM, or actual areaDetector drivers).

Note that the above discussion also does not mention the use of support/configure/EPICS_BASE.$(EPICS_HOST_ARCH) and support/configure/SUPPORT.$(EPICS_HOST_ARCH) which are used by all synApps support modules if building for Windows and Linux in the same tree. Andrew had suggested using RELEASE.local in place of these files, which would be fine with me, but we need to decide when we would make that switch.

[timmmooney]

The current version of support/Makefile does work with areaDetector. Here's an excerpt:
...
# areaDetector has differently named RELEASE files
RELEASE_FILES += $(wildcard $($(1))/configure/RELEASE_PATHS.local)
RELEASE_FILES += $(wildcard $($(1))/configure/RELEASE_PATHS.local.$(EPICS_HOST_ARCH))
RELEASE_FILES += $(wildcard $($(1))/configure/RELEASE_PATHS.$(EPICS_HOST_ARCH))
...

[MarkRivers]

@timmmooney that's great, sorry for the misinformation. I need to change my top-level synApps/support directory to point to Github, then I would have seen this.

[timmmooney]

Note that point (4) in the build requirements eventually ends up requiring Keenan Lang's March 2015 modification to release.pl to set EPICS_DISPLAY_PATH

[rsluiter]

This is how synApps and EPICSbase are distributed on /APSshare.
synApps distributions.pdf