README: expand on the pkg-config compatibility promise

A bunch of CMake developers, who apparently did not comprehend the previous
compatibility promise statement, decided to passive-aggressively demand we fix
their non-bug anyway.

Clarify in more detail what level of pkg-config compatibility we provide, and
mention that such passive-aggressive behaviour is considered a CoC violation.

Fixes #228.
pull/231/head
Ariadne Conill 2021-07-24 19:37:41 -06:00
parent fa859bb045
commit 9ea26eb913
1 changed files with 15 additions and 0 deletions

View File

@ -60,6 +60,10 @@ Doing so is discouraged by the [freedesktop tutorial][fd-tut] anyway.
## compatibility with pkg-config
I really hate that I have to have this section, I like being a nice person, but we
unfortunately have to say this because otherwise we get passive-aggressive people who
try to argue with us about what pkg-config compatibility means.
We do not provide bug-level compatibility with pkg-config.
What that means is, if you feel that there is a legitimate regression versus pkg-config,
@ -67,6 +71,17 @@ do let us know, but also make sure that the .pc files are valid and follow the r
the [pkg-config tutorial][fd-tut], as most likely fixing them to follow the specified
rules will solve the problem.
Additionally, **we do not consider pkgconf doing what you tell it to do, when pkg-config
fails to do so, to be a bug**.
If, for example, you use environment variables such as `PKG_CONFIG_SYSTEM_[INCLUDE|LIBRARY]_PATH`
and then find yourself surprised that `pkgconf` is stripping `-I` and `-L` flags relating
to those paths, it's not a `pkgconf` problem -- `pkgconf` is doing exactly what you told
it to do.
We will reject bugs like this, and if you choose to violate our [Code of Conduct](CODE_OF_CONDUCT.md)
by demanding we fix your non-bug, we will fix the problem by banning you from the repo instead.
## compiling `pkgconf` and `libpkgconf` on UNIX
pkgconf is basically compiled the same way any other autotools-based project is