Code review comment for ~bhill/epics-base:pvAccess-envDefs.h

Hi Bruce,

I don't understand your point about env variables getting defaults from other env variables, we don't do that.

The CA code uses the routines in envDefs.h to access environment variables, but because of our default mechanism (and to avoid confusion) the code calls them environment parameters. There is a script libCom/src/env/bldEnvData.pl that reads values from Base's CONFIG_ENV, CONFIG_SITE_ENV and any os/CONFIG_SITE_ENV.$(T_A) files and the envDefs.h header and generates an envDefs.c file containing those values, which the API then provides as the default value for a parameter if no environment variable by that name exists at run-time.

The PVA code does not currently use the routines in envDefs.h to access environment variables, so it can't rely on the default value mechanism of environment parameters. This was probably because it's not possible to add extra environment parameters in a sub-module or support module, they currently have to be listed in the envDefs.h file in libCom/env.

I do want to change the way that this code works so modules can define their own parameters and this is probably the right time to do that (after the 7.0.2 release), but exactly how that should work isn't completely clear without doing some more development.

The ENV_PARAM objects with their default values should be compiled into the library built by the module, so the bldEnvData.pl script will need to be modified to load a module-specific header file. How and where we specify default values (particularly for parameters that we expect sites to want to set themselves — they shouldn't have to edit CONFIG_SITE* files inside sub-modules) still needs some thought and discussion; it would be best to have that discussion before writing significant amounts of code to implement something.

- Andrew