[sane-devel] [PATCH 2/2] sane-config fix, don't provide random infos
Ruediger Meier writes: 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. +1 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. AFAIK, pkg-config support was added in 1.0.21 already. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
[sane-devel] [PATCH 2/2] sane-config fix, don't provide random infos
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
[sane-devel] [PATCH 2/2] sane-config fix, don't provide random infos
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-backends-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). 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? Nils -- Nils Philippsen / Wilhelmstra?e 22 / D-71229 Leonberg nils at tiptoe.de / nils at redhat.com PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 Ever noticed that common sense isn't really all that common?
[sane-devel] [PATCH 2/2] sane-config fix, don't provide random infos
From: Ruediger Meier ruediger.me...@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= + pkgconfig_package=sane-backends usage () -- 1.7.6.1
[sane-devel] [PATCH 2/2] sane-config fix, don't provide random infos
On Tuesday 07 February 2012, 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= + It's debatable wheather sane-config should find any other sane-backends.pc than the cleanly make installed one. If this would be wanted we could do only export PKG_CONFIG_PATH=@libdir@/pkgconfig without touching PKG_CONFIG_LIBDIR. But IMO that use case is already covered by directly using pkg-config. The way I did it here we can be more sure to include/link against that sane-backends the called sane-config belongs to. Also it's IMO worth to think about declaring sane-config deprecated to remove it completely in some years. cu, Rudi pkgconfig_package=sane-backends usage () -- 1.7.6.1
