Fetch epicsEnvVars data from CONFIG_ENV in EPICS base

[simon-ess]

Resolves #68

[simon-ess]

One downside about this, comparing the output before and after: we get a bunch of PV renames. That is, we switch from (for example)

• $(IOCNAME):CA_CONN_TIME -> $(IOCNAME):CA_CONN_TMO (relatively minor)
• $(IOCNAME):CAS_AUTO_ADDR -> $(IOCNAME):CAS_AUTO_BEACON_ADDR_LIST (much more major)

The upside is that we are much more explicit about the PV names in relation to the underlying EPICS variables. The downsides are that:

• We are changing PV names - this is going to cause a headach for some people, although we can put in an alias temporarily
• The second situation above is a worryingly long name; depending on one site's naming conventions we get close to some limits.

Thoughts, @nariox, @anjohnson ?

[nariox]

I do like having the PV name match the underlying variable.

As for the length, I don't mind the increase as much. From what I understand, the PV name length was limited to 40 chars up to base 3.12, after that the limit is 60 chars. ":CAS_AUTO_BEACON_ADDR_LIST" takes 26, which is quite a lot for someone using 3.12, but I think is fine for the 60 char limit. I imagine most people running the latest iocStats are not using epics-base from 30+ years ago (even 3.13.10 is over 20 years old now).

We could choose to ship the aliases for a single release cycle (3.3.x, but not 3.4.x), if we'd like to deprecate the old names eventually. I personally don't mind just keeping the aliases in (or maintaining it separately in my repo as long as the community has access to it if they want to find it). The aliases themselves are ready at #70. I have tried to look into a way to print a message when loading the aliases, but I couldn't find anything that wasn't too "hacky". Maybe creating a simple device support device that prints a deprecation warning in it's init function? Although I think it's not too much to expect maintainers to read the release notes carefully.

You do touch a good point on the facility specific rules, but I think it is okay to have the local maintainers create their own custom iocEnvVar.template or have it patched by adding something like sed -i 's/$(IOCNAME):CAS_AUTO_BEACON_ADDR_LIST/$(IOCNAME):CAS_ADDR_LIST/g' iocEnvVar.template in their local builds.

[simon-ess]

@nariox - I have updated this PR to add aliases to the old records, together with a deprecation note. Please let me know if this would work for you.

[nariox]

Hi Simon,
This looks good to me. I'd just cherry-pick commit 61abda4 so we avoid generating duplicate records if the variable is defined more than once.

[nariox]

I have resubmitted the duplicate removal as #74.