search

quixdb / squash-benchmark

Benchmarking all of the algorithms from Squash
https://quixdb.github.io/squash-benchmark/
MIT License
43 stars 10 forks source link

added variable to Makefile that helps switch between squash versions … #31

Closed psteinb closed 8 years ago

psteinb commented 8 years ago

…available through pkg-config

nemequ commented 8 years ago

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.

psteinb commented 8 years ago

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.

nemequ commented 8 years ago

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).

psteinb commented 8 years ago

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.