ci/woodpecker/push/woodpecker Pipeline was successfulDetails
cache functions are the hottest part of the pkgconf code when
profiled, by removing the linked list for lookups, we can turn
lookups into an O(k) operation
ci/woodpecker/push/woodpecker Pipeline was successfulDetails
This is required to make the pointer safely re-usable after being freed,
otherwise the list still says that it has nodes, but they point nowhere.
This is particularly important for libpkgconf, if a caller needs to
re-enter the library after freeing a path in a static path (such as the
default personality)
Instead of a bool. The latter will result in de-initing leaving the
library unable to init again, which works out for the cli, but is
problematic for other consumers (meson++ and muon).
v2: - Add docs that the functions are not thread safe
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
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>
Ariadne Conill
Dylan Baker
data-man
Andrea Pappacoda