> Firstly, please convince me why this is necessary?  A package can set
> environment variables on most on Linux distributions by adding files to
> /etc/profile.d and users can override them in ~/.login ~/.cshrc or ~/.profile
> as they wish.

Which shell (sh, csh)?  Environment variables are a poor way to do configuration.

>  IOC startup scripts may contain epicsEnvSet commands.  Why do
> we need yet another way to set environment variables?

For IOCs you don't.  This is for EDM, ALH, channel archiver, and my python scripts.  Client applications which run on something other then vxworks or rtems.

The intent is to allow libca to be configured in the way that almost all other applications/libraries are.

> 
> If we do provide this facility, people are going to want to use it on all IOC
> architectures, so implementing it on just one OS is not a good idea.  I accept
> that it was designed for Linux, but I know that someone like Ernest Williams
> is going to want to use it on vxWorks or RTEMS if we don't provide it in the
> initial release.

I don't see any reason to use it work on an embedded system.  There it gives no benefit over epicsEnvSet and IOC configuration would require yet another file.

> The current code is not portable to vxWorks.  The setenv() routine is not
> available there, use  epicsEnvSet() or putenv() instead.

Ah, I will do this.

> We also have problems using C++ STL containers on vxWorks.  No other code in
> the IOC uses them because STL containers create and destroy objects a lot,
> which used to cause major memory fragmentation in the vxWorks memory
> allocator; not sure if it still does, although that shouldn't be a problem
> with this code.  However since the IOC hasn't needed it before and memory is
> precious on embedded systems, most sites don't build the STL support package
> into their vxWorks OS images, and for a minor change this will cause major
> pain.  I got lots of very ugly "undefined symbol" errors for internal STL
> routines when I tried to load the fileLoad.o file on one of my boards here.
> Note also that as written the vxWorks linker does not include this file in the
> executable it generates, since no symbols reference it; that's why I had to
> explicitly load the fileLoad.o object by hand.

So maybe this should be host only...

> 
> The list of files to load should not be hard-coded in the source to
> fileLoad.cpp.

Configuration files don't work unless people know where they are.  Uniformity is important.  It should follow the conventions of the host OS.  Currently fileLoad just has the *nix set.  A set of paths for Windows is also needed.

> Define a new parameter called EPICS_CONFIG_PATH which is set in
> base/configure/CONFIG_ENV and read using an envGetConfigParam*() routine.  Its
> value probably needs to be architecture-specific though and we don't currently
> have a mechanism to set default values from an arch-specific file, so
> bldEnvData.pl needs to be changed to handle that and some architecture-
> specific files added.

#ifdef I_don_t_have_a_better_answer_then_

> How to specify multiple files in one parameter?  Use OSI_PATH_LIST_SEPARATOR
> from osiFileName.h so the value looks like that of a regular ...PATH
> environment variable except it points to files, not directories.

Is a fully dynamic search path really needed?  The main reason for having a config file is to avoid having to set up the environment.  The end user is free to set $EPICS_CONFIG, ~/.epicsrc, and/or $PWD/epics.config while a sysadmin can set /etc/epics.conf to give machine defaults.

However, I think I will try to use in the EPICS_BASE location given at compile time like softIoc does.