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.
Prior to this commit, the code path responsible for prefix redefinition
(motivated by --define-prefix or otherwise) was visited more than
once, specifically since the check ignored pkg->owner->prefix_varname.
The current approach was to parse the .pc and, detect the prefix, throw
everything together and at the end replace all \ with / to not produce invalid
escape sequences.
This has the problem that escaping in .pc files is ignored and no longer
possible. Also in case the prefix path has a space in it the result would be
invalid because of missing escaping.
This changes the following things:
* We no longer normalize values at the end. Instead we assume .pc files use "/"
as a directory separator or "\\", same format as under Unix. "\" alone no
longer works. This shouldn't be a problem since most build tools produce .pc
files with "/" like meson, cmake, autotools.
* When injecting the prefix at runtime we convert the prefix to use "/" and
escape spaces so that in combination with the .pc content the result is a
valid escaped path value again.
This patch has been used in MSYS2 for some months now.
See #212
On Windows, pkgconf redefines the prefix by default.
This gives the user the option to disable this behavior via an environment variable.
The benefit of an environment variable is the user can change this behavior when
using a build system such as cmake or meson, which may not expose this
parameter to the user.
To avoid a crash on some platforms (like Darwin 9) provide a buffer to
realpath(3).
Darwin 9 (last PPC target) documents realpath needs to be given a buffer
to the resolved_path argument large enough to hold PATH_MAX bytes.
With NULL argument it crashes. Solaris makes no mention of
resolved_path to be allowed NULL, yet recent versions accept it and
malloc(3) accordingly.
Because the documentation explicitly mentions PATH_MAX being the limit
to what realpath(3) would write in resolved_path, switching to a static
buffer here doesn't limit resolution compared to dynamically allocating
a buffer by realpath(3).
While this change requires a bit more space on the stack, it avoids a
malloc/free sequence, and allows successful operation on (older)
platforms that lack support for dynamically allocating a return buffer
in realpath(3).
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
when using library() instead of shared_library() the user can decide
to build a shared or static version, or both. The default is still shared
as before.
This mirrors what the autotools based build sysstem can do.
olf
Ariadne Conill