Add ability to override iolibs/camlibs dirs at runtime

[trilader]

In an application I am developing I have the need to set the path for camlibs and iolibs at runtime as I don't know where the libraries will be when I build the library. This allows for creating a portable version of libgphoto2 which is not dependent on the install location (on macOS you need to use install_name_tool and otool to fix the dyld-id and locations of dependent libraries as well).

With this patch the override path has precedence over the location embedded by configure but will still be overwritten by the environment variables if present so the user/system administrator can still use their own versions of the libraries if they want.

I've tested this patch on Windows, Linux and macOS (x86, gcc and clang).

[hfiguiere]

what's wrong with using setenv?

[trilader]

On Windows I'm using MinGW which doesn't have/support setenv (at least on on 9.2.0 with the latest released runtime v7)

[hfiguiere]

There is this: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setenvironmentvariable

Doesn't that work ?

(I just googled it, I don't do Windows)

[trilader]

I've not checked SetEnvironmentVariable but found out that I could use putenv on Windows.

What I've not considered before is that using the environment variables will pollute the environment of other applications I'm spawning of which I don't know if they would use the CAMLIBS/IOLIBS variables by themselves (they're user provided).

[ndim]

As mentioned in #796, adding a function for overriding the camlib and iolib dirs with one API call for camlibs and one API call for iolibs might become obsolete soon. When we integrate the two configure.ac buildsystems for libgphoto2 and libgphoto2_port into one, the install location for camlibs and iolibs will be fixed relative to each other, so a single API call will do the job there and adding two API calls makes no sense any more.

And in case we ever manage to build the iolibs into the libgphoto2_port.so and the camlibs into the libgphoto2.so file, we would not even need a single API call any more.

As the environment variable method already exist to point libgphoto2_port and libgphoto2 to their respective drivers, no API calls should be added providing this functionality.