On Tue, 28 Sep 2021 13:41:05 +0100
Jim Easterbrook <j...@jim-easterbrook.me.uk> wrote:
> I've recently added "binary wheels" to my Python interface to
> libgphoto2. These include pre-built copies of libgphoto2 v2.5.27 and
> are much quicker and easier for a user to install as they don't have
> to install libgphoto2 (development headers) and compile the interface
> files.
>
> One problem I encountered was the hard coding of absolute paths into
> where libgphoto2 looks for its camlibs and iolibs. Luckily the
> CAMLIBS and IOLIBS environment variables solve that problem, but I'd
> rather they weren't labelled as for "broken/test installations".
I have just changed the wording for IOLIBS and CAMLIBS to: "You only
need this with non-standard installations."
If it helps you in any way, we now (i.e. in 2.5.27.1 in git since commit
94d9912e from 2021-10-12) a way to build libgphoto2 and libgphoto2_port
such that the default location it looks for camlibs and iolibs can be
set at configure time:
configure \
camlibdir=/where/to/install/the/camlibs \
DEFAULT_CAMLIBS=/where/to/find/the/camlibs \
iolibdir=/where/to/install/the/iolibs \
DEFAULT_IOLIBS=/where/to/find/the/iolibs
The defaults should be sane:
* If camlibdir= is not set at configure time, use a default location
based on ${libdir} to find out where to install the camlibs.
* If DEFAULT_CAMLIBS is not set at configure time, use the value of
${camlibdir} to find out where to look for the camlibs.
* Analogous behaviour for iolibs.
What we do not have at this time is a way to change the driver lookup
location at runtime with an API function call. That has been proposed
in https://github.com/gphoto/libgphoto2/pull/534 but I have
not thought much about it so far. I certainly do not want to hurry
changes to the public API and ABI as those tend to stick for a long
time.
Uli
_______________________________________________
Gphoto-devel mailing list
Gphoto-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gphoto-devel
