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)