added variable to Makefile that helps switch between squash versions … #31
Conversation
…available through pkg-config
|
Thanks for the patch, but unfortunately squash-0.7 and squash-0.8 are not API-compatible (hence the error you're seeing in #30). Making this work would require placing some ifdefs in the code, and I don't think it's worth it. We're working on getting Squash API stable soon. Once that happens pkg-config names will no longer change between versions. |
|
Thanks for getting back to me. IMHO, a pkgconfig should not contain a
version ID in the first place. If this goes away anytime soon, then I am
fine with closing this PR.
|
|
Including the API version in a pkg-config name is pretty standard practice since changing the pkg-config name is the only way to signal that the API is incompatible. From pkg-config's point of view an API is compatible with all later versions of the same module name, even if the major version number changes. It may seem a bit weird, but if pkg-config treated different major versions of the same package as incompatible then it wouldn't be possible to have multiple major versions installed in parallel. Once Squash is API stable the pkg-config name will be squash-1.0 and it will stay that way for the foreseeable future (until an API break necessitates changing it to squash-2.0, which may never happen). |
|
Evan, I see your point and I would still disagree. What you say makes
sense, if squash-xx.pc is located in a central system wide path, say
/usr/lib/pkgconfig/. If I have multiple versions of the same package,
then you definitely want the version ID in the pkg-config filename
there. I agree on this.
Even though this practise may be standard, that does not imply that it
is a good practise. ;) For me as a developer that works on client
software of libsquash for example, I personally want to change the
environment of my build (export
PKG_CONFIG_PATH=/path/to/libsquash/master/lib/pkgconfig) rather than
changing e.g. variables in my build system or CMakeLists.txt or
Makefile. So maybe it boils down to the way you work.
On a side note: I never understood really how packages include their
version string in pkgconfig or even library names such as libpng12.so
which is now at available as 1.6.12 in stable release. Given the
flexibility of the bash environment, this feels more like a code smell
than a good practise.
|
…available through pkg-config