Simplify build configuration

[anjohnson]

Hi Mark,

This is a work-in-progress proposal for reducing the number of configure/RELEASE* files that users have to edit to be able to build areaDetector, aligning the configuration a lot closer to most other modules and allowing the Sumo tool to be used. If you are happy with these changes in principle I will work on modifying the other configure/EXAMPLE files and the documentation to match before completing the PR.

• Andrew

---

Generate RELEASE_LIBS. and RELEASE_PRODS. files
in configure/Makefile using paths from the configure/RELEASE and
other standard EPICS RELEASE.local and RELEASE..local
include files.

For the standard files to work I had to rename configure/RELEASE.local
which I have called configure/SITE_MODULES.local; the build also reads
an optional configure/SITE_MODULES..local file for host-specific
overrides as before. An EXAMPLE_SITE_MODULES.local file is included here.
I will rename the other EXAMPLE_RELEASE.local* files and update the
scripts and documentation in a subsequent commit before submitting the PR.

This change does not require any changes to the submodules since they use
the top-level configure/RELEASE_LIBS_INCLUDE and RELEASE_PRODS_INCLUDE
files which now pull in the new generated files from the $(TOP)/cfg/
directory.

Motivation: This makes configuring the paths for areaDetector support
modules follow the EPICS standard, simplifying the process for users and
allowing it to be built using the EPICS Sumo software from BESSY. Sumo
completely replaces the RELEASE file of every module it builds with a new
file specific to that module which points to all the support modules it
depends on. Sumo can only create one RELEASE file for each module though.

[anjohnson]

I'd forgotten this PR was submitted as a draft, but I was hoping for some comments on the approach.

I will rebase this PR against the latest AD Master branch and mark it ready for review.

[MarkRivers]

@anjohnson sorry for not commenting earlier. This looks like a good approach to me.

Is there a minimum version of base to support the /cfg directories?

Can you update areaDetector/docs/source/install_guide.rst as part of this PR?

[MarkRivers]

@anjohnson I have some time to work on this. Can you get it ready to pull? I'd like to pull it into a branch on Github, not into master to start with. How do we do that?

[anjohnson]

Hi Mark, sorry for the long delay. I've just rebased and pushed my latest changes including updating the docs/source/install_guide.rst to match. Please take a look when you have time.

My aim has been to try and make areaDetector match how other EPICS modules get configured; unfortunately you originally picked some subtly different ways to do things than are now more common EPICS standards, so unification may need existing build configurations to be redefined.

One of my changes reverses the order of the -include statements at the end of the configure/RELEASE file. In 3-11 it pulls in the $(TOP)/configure/RELEASE.local file before the $(TOP)/../RELEASE.local and $(TOP)/../RELEASE.$(EPICS_HOST_ARCH).local whereas other modules such as Asyn and the makeBaseApp template read the files from the parent directory files first. I realized while reviewing the documentation for updates that changing the include order will subtly affect how you override the SUPPORT path across different architectures.

One change that I would like to make but haven't is to rename the CONFIG_SITE.local.* files – as with RELEASE*.local and the new SITE_MODULES*.local files the normal EPICS convention is that the .local part of a filename should appear at the end of the name. That would allow the .gitignore file to just contain /configure/*.local although with all of areaDetector's EXAMPLE_* files that doesn't work. I might have used the convention *.local.example for those filenames myself, but I'm not sure that it's worth changing them all now.

Are you wanting to pull this into a branch in areaDetector so you will be able to push changes to it yourself? Github now lets maintainers of the target of a Pull Request push changes to the original PR branch even if it's in someone else's fork – there is a check-box in the right-hand column of the PR labelled "Allow edits by maintainers" which lets me control whether you can push to my branch, so I don't see that as necessary. I don't have write access to your repo so I couldn't push to a new branch myself, although you can of course pull from my branch do that push yourself if you really want to.

[anjohnson]

Wah? why did it close the PR? Trying to reopen it...

[anjohnson]

Okay, my mistake.