Hi Paolo, * Paolo Bonzini wrote on Tue, Nov 09, 2010 at 08:14:39PM CET: > This patch simplifies the overly complicated rules for ACLOCAL_PATH > vs. @automake_includes and @system_includes, by stating that > ACLOCAL_PATH will override even @automake_includes. The simplest > way to achieve this is to remove @automake_includes altogether.
I've read the previous discussion about this now, but I'm still not sure I understand the rationale for this change. Is it because you want to actually be able to override the $(datadir)/aclocal-$VERSION files with this variable? If so, why? I guess in that case it would be good to have another test to ensure that this happens, and is intentional. If the only reason is that --acdir doesn't accurately reflect what would happen after 'make install', maybe we can instead fix --acdir? The other changes in this patch seem fairly benign to me. I'm not sure if you stated whether the testsuite passes for you with this patch series. Thanks, Ralf > * NEWS: Adapt to change in ACLOCAL_PATH semantics. > * aclocal.in (default_automake_dir): New. > (scan_file): Use it to distinguish FT_AUTOMAKE from FT_SYSTEM. > (automake_includes): Remove. > (scan_m4_files): Do not scan it. > (have_ac_dir): New. > (parse_arguments): Set it for --acdir instead of automake_includes, use it > to determine whether to filter absent directories out of @system_includes. > Allow >1 directory in @system_includes for --print-ac-dir. > * doc/automake.texi: Adapt to changes in ACLOCAL_PATH semantics. > * tests/acloca25.test: Likewise.
