On Monday 08 November 2010, Ralf Wildenhues wrote:
Hello Stefano,
Hi Ralf.
Wouldn't this report have been better suited for bug-automake, especially
now that you've gone through the hassle of setting that up as a real bug
tracker?
Anyway ...
backcompat4.test is failing for me, see below.
Hello automakers.
The attached patch extend and impove the tests on `+=' support (for
appending to variables at automake time).
Since the maint branch has recently seen a commit dealing with
this feature (precisely, v1.11-222-g7a020d6 Fix a bug in variable
concatanation with `+='.), I'd like to
* Stefano Lattarini wrote on Tue, Nov 09, 2010 at 12:30:56PM CET:
Wouldn't this report have been better suited for bug-automake, especially
now that you've gone through the hassle of setting that up as a real bug
tracker?
Sure, I guess.
backcompat4.test is failing for me, see below. This
This series is v2 of the patch to add a per-user search path to aclocal.
v2 includes Stefano's testcases, and implements his suggestions about
search path ordering.
However, careful analysis of what happens during the automake build
showed that the resulting order is a bit more tricky than what
This updated patch passes the tests suggested by Stefano. Considering
that Automake will rarely if ever be invoked from outside, MSYS, I stuck
with the colon as the sole separator for ACLOCAL_PATH.
The test suites leaves the user's ACLOCAL_PATH in place, for consistency
with the treatment of
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.
There are two small visible
As suggested in the v1 thread, this renames references to user/system
includes to local and global. The source now refers to system
directories as a subset of the global directories (together with
ACLOCAL_PATH-supplied and dirlist-supplied directories).
* aclocal.in (user_includes): Rename to...