On Fri, 2025-08-08 at 10:42 -0400, Luiz Augusto von Dentz wrote: > Hi Bastien, > > On Thu, Aug 7, 2025 at 11:51 AM Bastien Nocera <hadess@xxxxxxxxxx> > wrote: > > > > This fixes the installed directory hierarchy not matching the > > source > > directory hierarchy. > > Ok, but why do we need to do such a change? Doesn't meson handle > installing in a different directory? If it doesn't you can probably > state it or point to the documentation. The problem isn't installing to a different directory, but the fact that public headers which mention "#include <bluetooth/bluetooth.h>" will actually want to include "lib/bluetooth.h" when building inside the bluez repo. The autotools way was to hack it by linking all the "lib/*.h" headers into "lib/bluetooth", it's just as easy renaming them all, rather than perpetuating that hack into the meson build system. The idiomatic way to do things, in autotools just as in meson, would be to have the header directory in the sources to be the same as when installed to /usr/include, not to use symlink'ing hacks. We could also rename the top-level "lib/" directory to "bluetooth/", but that would be slightly non-descript when reading the sources. I haven't looked at implementing the same autotools hack in meson, because it seemed like a better idea to just fix things, rather than continue with the brokenness. It might be possible with meson.add_postconf_script(): https://mesonbuild.com/Reference-manual_builtin_meson.html#mesonadd_postconf_script But I'd really rather fix this hack. Let me know what you think.
