Build systems like cmake try to mimic the search ordering for libraries and
replace the search path -L -l pair with something like -l/usr/lib/libfoo.a,
which is entirely equivalent. Linker search path resolution on posix-ish
systems is well standardized, more so than compiler header searches,
because the linker in the common case comes from the OS vendor, not the
compiler toolchain vendor. Replication is easier than with compilers with
the various combinations of flags to push directories into various places
in the search list and the various ways of spelling the file to include
with "" or <> and relative, absolute, or unqualified header names.


On Fri, Feb 11, 2022 at 6:22 PM David Blaikie via SG15 <
sg15_at_[hidden]> wrote:

> On Fri, Feb 11, 2022 at 2:37 PM Daniel Ruoso <daniel_at_[hidden]> wrote:
>
>> On Fri, Feb 11, 2022 at 5:28 PM David Blaikie <dblaikie_at_[hidden]> wrote:
>> > It seems unfortunate to lose some of the portability provided by
>> relative paths to interface definitions when having the metadata file in
>> the include path instead of the library search path
>>
>> Yes, but, as I mentioned in the previous email, it also means we
>> ensure that you're getting the metadata to parse the interface unit
>> that matches the library artifact you're going to consume. I think
>> that's not an insignificant win.
>>
>
> Compared to consistency with the header files? I guess either way there's
> a chance of mismatch. (would it be really bad to do header search but using
> the library name? having the metadata in the header search path, but based
> on library name (solving the config-per-module V config-per-library) - I
> guess that's a more novel search, rather than something closer to an
> existing search process/path/etc (but it's not like we can actually use the
> linker search path resolution, can we? - the linker doesn't generally
> report the paths it actually found in a machine readable way that the build
> system could then just swap the extension on and check for existence), but
> would allow the metadata to be more portable/have relative paths to
> headers)
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>