Fair enough - appreciate the thoughts/considerations.

On Fri, Feb 11, 2022 at 4:36 PM Steve Downey via SG15 <sg15_at_[hidden]>
wrote:

> 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
>>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>