My take as a nix user.

On Thu, 21 Mar 2024, 02:08 Ruki Wang via SG15, <sg15_at_[hidden]>
wrote:

> Hi, all
>
> As far as I know, there are currently a number of ways to find libraries
> from the system and package manager:
>
> 1. cmake find_package and its .cmake import file
>

IIRC, find_package traverses the CMAKE_MODULES_PATH environment variable.

2. pkgconfig and .pc files
>

IIRC, pkgconfig traverses the PKG_CONFIG_PATH environment variable.

3. directly from the system library path, e.g. /usr/lib ...
>

More generally, traversing LD_LIBRARY_PATH (otherwise nothing would work on
nixos, as it has no /usr/lib - everything is done through, you named it,
environment variables)

If we just specify a uniform package metadata format to get this library
> information. Then where should this metadata file be stored?
>

Where ever the package manager wants to store it. Some may want to use a
system directory, some may want to use a directory within a managed root
path (e.g. bazel), some may want to micromanage each dependency and pass a
flood of information to the build system (e.g. nix).

The one thing I wouldn't be happy with is if it is a requirement to provide
this metadata file inside of the link directory, for instance. It should be
an option, but I'd want such information to be stored entirely separate
from the library's shared object directory. This allows existing shared
object directories to be left untouched, which makes their hashes
unchanged. If we were to expect a new file to be added to any library we
wanted to import, I would have to rebuild my entire system as most of
nixpkgs would be invalidated (the output directory hashes would change).

It could be possible to avoid a full rebuild by wrapping the existing
library, copying/symlinking files over, then adding a new file on top, but
that would be quite painful. It would be far less cumbersome to add (into
nixpkgs) an additional, separate output for libraries.

How should the build system find it?
>

Environment variables are the only way I can think of that would work for
me. And there's strong precedent for using them for this purpose

I think this would suffice for the Unix family of systems. I don't know
about Windows - I know that environment handling is different enough in
Windows for nix to be a no-go there. That's all I know, though.