On 17 Dec 2024, at 17:17, Nick Bowler <nbowler@xxxxxxxxxx> wrote: > Adding the automake list, because (mostly for historical reasons) > aclocal is actually part of automake, not autoconf. I’ve been using autotools for too many years and I _still_ forget what tool is where… Though considering what it does, it really should be in autoconf, right? > On 2024-12-17 11:01, Ross Burton wrote: >> I’m trying to clean up our autoconf invocation and want to do things >> the “right” way. >> >> We’re in a cross environment with split native/target sysroots which >> makes things interesting, as this means there are two places which I >> consider the “system ac directories”, the target and the native. > > I don't really get it, why you would need different autoconf macro > directories for "the target and the native", but ok... We need to build autoconf-native into the native sysroot so we can run it on the build machine, obviously. Then eg pkgconfig-native is needed as pkgconfig is a build-time binary, and that installs m4 macros into the native sysroot. Then a target package may depend on something like target libxml2 and its libxml2.m4 which will be in the target sysroot. So, aclocal needs to be able to find macros in the target and native sysroots. >> Unfortunately you can’t pass a colon-separated list for —system-acdir >> so right now we’re effectively doing: > > I believe the dirlist mechanism[1] for aclocal can be used to achieve > the result you are trying to achieve. > > Either put a dirlist file in the specified directory which points to the > other one, or specify a totally different directory containing a dirlist > file that refers to both. Interesting. I’ll have a read. Thanks, Ross IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
