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
2. pkgconfig and .pc files
3. directly from the system library path, e.g. /usr/lib ...
4. from some package managers, homebrew, vcpkg, conda, pacman, apt ...

In the current xmake build system, if the user wants to use the system
libraries, the libraries will be found from these cases as much as possible.
I think that a standard to converge these cases is necessary, which can
simplify the build system to find libraries.

If we just specify a uniform package metadata format to get this library
information. Then where should this metadata file be stored? How should the
build system find it? Do we need to provide a tool like pkg-config?
Also, do we need to make all build systems and package managers provide an
additional package metadata file when installing a package? For example,
cmake now has its own .cmake library import file format.

Also, some package managers don't install packages directly into the system
path, e.g. conan, nixpkgs, and it's a bit complicated to find the package
metadata file from them, and there's no standardised way to do it.

Ruki Wang

Daniel Ruoso via SG15 <sg15_at_[hidden]> 于2024年3月20日周三 19:09写道：

> On Wed, Mar 20, 2024, 19:44 Boris Kolpackov via SG15 <
> sg15_at_[hidden]> wrote:
>
>> I have doubts that it will be possible for the NxM
>> case where each element on either side is controlled by an
>> independent entity.
>>
>
> I think it is important to clarify that the goal here is not to come up
> with the one system to rule them all.
>
> For instance, let's consider a system like Debian, where you can rely on
> the Linux filesystem hierarchy standard and with the fact that the
> dependencies will be self consistent abi-wise.
>
> In that case, producing a "target model" for satisfying dependencies for a
> build system is fairly straightforward, in fact, we just need a richer
> metadata format than what pkg-config does, but the principle of how it
> works would be mostly sufficient.
>
> However, if you look at the HPC environment, where ABI and Hardware
> compatibility is managed in a completely different way, you wouldn't be
> able to solve the problem the same way.
>
> The immediate goal here, given the above, is just to establish an
> interoperability language that would allow the different systems used on
> those environments to tell the build system (e.g.: cmake) what is the
> "target model" for the libraries being provided.
>
> Daniel
>
>> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>

-- 
_______________________________________________
Ruki Wang