On Monday 03 September 2012, Nils Philippsen wrote: > Hi there, > > I should probably monitor sane-devel more closely (sue me ;-)). > > On Tue, 2012-02-07 at 21:24 +0100, Ruediger Meier wrote: > > From: Ruediger Meier <ruediger.meier at ga-group.nl> > > > > This got broken in 26ea2a25. > > If we configure --prefix=/tmp/bla then /tmp/bla/bin/sane-config > > should tell us the right things instead of using any default search > > paths. --- > > tools/sane-config.in | 4 ++++ > > 1 files changed, 4 insertions(+), 0 deletions(-) > > > > diff --git a/tools/sane-config.in b/tools/sane-config.in > > index 1fae2e5..8e4b52a 100644 > > --- a/tools/sane-config.in > > +++ b/tools/sane-config.in > > @@ -10,6 +10,10 @@ scriptname="sane-config" > > prefix="@prefix@" > > exec_prefix="@exec_prefix@" > > > > +# using our installed *.pc only - neither default nor user paths > > +export PKG_CONFIG_LIBDIR="@libdir@/pkgconfig" > > +export PKG_CONFIG_PATH="" > > + > > Well, this ^^ broke multilib again in 1.0.23 (but it's really my > fault for not spotting this earlier): it makes the sane-config script > differ between 32bit and 64bit installation, which prevents > installing both 32bit and 64bit versions of development packages > (which usually contain it) on the same machine, see: > > https://admin.fedoraproject.org/updates/FEDORA-2012-13142/sane-backen >ds-1.0.23-1.fc17 > > I agree that there should be a way to have sane-config produce the > correct information if someone installs sane-backends into a private > prefix (as long as we have it -- can we get rid of it pretty > please?), but it should also work for both bit sizes when installed > system-wide. I mean if someone used sane-config installed into > /usr/bin it should work for building binaries for either ix86 or > x86_64 if both variants are available. This was the intention of my > original patch, i.e. defer the decision about 32bit/64bit to > pkg-config which uses /usr/lib64/pkgconfig or /usr/lib/pkgconfig > respectively, depending on the desired variant (i.e. default or > whatever the user selected with setarch).
As I mentioned in one of my other emails in this thread I'd recommend to declare sane-config deprecated (print a warning) to let developers use pkg-config directly. This is IMO much better than changing sane-config's current behavior just to make it usable for multiarch cases where it wasn't made for. > BTW, now that I think about it the patch above will become faulty as > soon as our *.pc file correctly specifies dependencies, i.e. listing > libraries on which sane-backends depends on the "Requires:" line > instead of hard-coding the flags in "libs". In that case, pkg-config > won't know what flags to use since we forbade it to look in its > default location. > > Any ideas how to tackle this conundrum? You could provide patches to 3rd party projects which are currently using sane-config to use pkg-config instead. Note that then these projects will require sane-backends >= 1.0.23 if you don't keep a sane-config fallback. cu, Rudi
