On Fri, Feb 11, 2022 at 2:37 PM Daniel Ruoso <daniel@ruoso.com> wrote:
On Fri, Feb 11, 2022 at 5:28 PM David Blaikie <dblaikie@gmail.com> 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)