"Derek R. Price" wrote:
> Okay, I fixed this as well as all the special casing of '.' that the code is
> littered with FIXME comments about. I've included ChangeLog entries in the patch
> as well as a new test case, but here's a bit more detail:
Is there some reason this patch was never checked
"Derek R. Price" wrote:
> 2) In the case of $config_aux_dir, I removed all the switches on '.' and '' and
> replaced three with a switch on a new variable $config_aux_dir_set_in_configure_in
> (yeah, I know that's a little long, but it sure is easy to interpret) which is set
> when AC_CONFIG_AUX
Okay, I fixed this as well as all the special casing of '.' that the code is
littered with FIXME comments about. I've included ChangeLog entries in the patch
as well as a new test case, but here's a bit more detail:
1) In the @require_file_paths case (since it only subbed $relative_dir for '.',
Unfortunately, not quite. This causes depcomp to be incorrectly pushed
onto DIST_COMMON in the sudir/Makefile.in when maybe_push_required_file
gets called by require_file_internal. Basically,
maybe_push_required_file expects $relative_dir to be set right and pushes
its file onto DIST_COMMON if $
The CVS automake, using --add-missing and not using AC_CONFIG_AUX_DIR,
is placing depcomp in whatever directory it first encounters C files in
then looking for it during configure in $(top_srcdir).
The problem appears to start on line 3054 of automake.in (in the
handle_dependencies function):
