Re: bug: depcomp misplaced
"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 in? Is there anything I can do to help? I'm pretty sure it was the correct fix. I'm available for email or *gasp* phone consultation if anyone has any questions about it. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not bury the new kid. I will not bury the new kid. I will not bury the new kid... - Bart Simpson on chalkboard, _The Simpsons_
Re: bug: depcomp misplaced
"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_DIR is noticed initially since it seemed a little silly to > check _every_ use of $config_aux_dir for '.' and '' for only three places which > wanted to look in a local directory rather than use AC_CONFIG_AUX_DIR's actual > value. I should have specified $config_aux_dir rather than AC_CONFIG_AUX_DIR in the last reference of this explanation, as the code sets $config_aux_dir to one of the default locations (it could be '.', '..', or '../..', depending on where the first config file is found) and _this_ is what the code which now switches on $config_aux_dir_set_in_configure_in is avoiding. If AC_CONFIG_AUX_DIR was used that code will use the specified value. Hence the variable name. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- There are plenty of businesses like show business. There are plenty of businesses like show business. There are plenty of businesses like show business... - Bart Simpson on chalkboard, _The Simpsons_
Re: bug: depcomp misplaced
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 '.',
all that was required was to pass in $relative_dir instead of '.' for the three
locations that mattered). This is what actually fixed the depcomp bug since
@require_file_internal now only looks in $relative_dir when specifically &
literally requested.
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_DIR is noticed initially since it seemed a little silly to
check _every_ use of $config_aux_dir for '.' and '' for only three places which
wanted to look in a local directory rather than use AC_CONFIG_AUX_DIR's actual
value.
3) Added a test case which confirms that depcomp is added correctly when two
subdirs contain C source.
4) Based on the assumption that depcomp is a new feature which has never been out
of alpha, depcomp is now restricted to the same locations as the other build
scripts (install-sh, missing, & mkinstalldirs). Allowing it to also be in any
directory containing a C source file would be trivial, but I didn't think it was
important.
5) tweaked two test cases to look for $(top_srcdir)/depcomp rather than
csubdir/depcomp.
This is good stuff. I'm pretty sure it should be checked in, but please,
questions, comments?
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
Round up the usual suspects.
- Claude Rains as Captain Louis Renault, _Casablanca_
"Derek R. Price" wrote:
> 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 $relative_dir/$file exists. Unfortunately
> $relative_dir gets set back to normal after require_config_file returns
> and then DIST_COMMON gets written out into the wrong Makefile.in. Or,
> rather, the correct Makefile.in but containing the wrong 'depcomp'
> reference. I'm too tired and hungry to try and decipher any more right
> now. Anyone have any better ideas?
>
> I've included my patch containing what I have so far since it fixes some
> tests which should be fixed in case anyone wants to take a look before
> I wake up from my nap and get something to eat. Or in case I find
> something better to do since I do have that workaround and other things
> I could be working on. pr87.test and subdir4.test are still failing
> because of this. Sorry about the rewritten toplevel Makefile.in, but
> I figured I might as well include it since it gets rewritten on the first
> make after a fresh checkout right now anyhow. Oh, and I removed a hack
> from automake.in that became unnecessary after $relative_dir was
> redefined for require_config_file. Or what should still be an
> unnecessary hack after this problem gets fixed.
>
> Derek
>
> --
> Derek Price CVS Solutions Architect ( http://CVSHome.org )
> mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
> --
> 82. Hold a hard drive to your ear -- listen to the C.
>
> Raja R Harinath wrote:
>
> > "Derek R. Price" <[EMAIL PROTECTED]> writes:
> > > The problem appears to start on line 3054 of automake.in (in the
> > > handle_dependencies function):
> > >
> > > # Set location of depcomp.
> > > local ($prefix) = ($config_aux_dir_specified ? $config_aux_dir
> > > : '$(top_srcdir)');
> > >
> > > &define_variable ('depcomp', "\$(SHELL) $prefix/depcomp");
> > >
> > > &require_config_file ($FOREIGN, 'depcomp');
> >
> > I remember that playing around with $relative_dir worked at some time.
> > I don't have CVS automake checked out right now, but can you try
> > replacing the last line above
> >
> >&require_config_file ($FOREIGN, 'depcomp');
> >
> > with the following hack
> >
> >local ($save_dir) = ($relative_dir);
> >$relative_dir = '.';
> >&require_config_file ($FOREIGN, 'depcomp');
> >$relative_dir = $save_dir;
> >
> > - Hari
> > --
> > Raja R Harinath -- [EMAIL PROTECTED]
> > "When all else fails, read the instructions." -- Cahn's Axiom
> > "Our policy is, when in doubt, do the right thing." -- Roy L Ash
? automake/tests/depcomp.test
Index: automake/automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.803
diff -u -r1.803 automake.in
---
Re: bug: depcomp misplaced
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 $relative_dir/$file exists. Unfortunately
$relative_dir gets set back to normal after require_config_file returns
and then DIST_COMMON gets written out into the wrong Makefile.in. Or,
rather, the correct Makefile.in but containing the wrong 'depcomp'
reference. I'm too tired and hungry to try and decipher any more right
now. Anyone have any better ideas?
I've included my patch containing what I have so far since it fixes some
tests which should be fixed in case anyone wants to take a look before
I wake up from my nap and get something to eat. Or in case I find
something better to do since I do have that workaround and other things
I could be working on. pr87.test and subdir4.test are still failing
because of this. Sorry about the rewritten toplevel Makefile.in, but
I figured I might as well include it since it gets rewritten on the first
make after a fresh checkout right now anyhow. Oh, and I removed a hack
from automake.in that became unnecessary after $relative_dir was
redefined for require_config_file. Or what should still be an
unnecessary hack after this problem gets fixed.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
82. Hold a hard drive to your ear -- listen to the C.
Raja R Harinath wrote:
> "Derek R. Price" <[EMAIL PROTECTED]> writes:
> > The problem appears to start on line 3054 of automake.in (in the
> > handle_dependencies function):
> >
> > # Set location of depcomp.
> > local ($prefix) = ($config_aux_dir_specified ? $config_aux_dir
> > : '$(top_srcdir)');
> >
> > &define_variable ('depcomp', "\$(SHELL) $prefix/depcomp");
> >
> > &require_config_file ($FOREIGN, 'depcomp');
>
> I remember that playing around with $relative_dir worked at some time.
> I don't have CVS automake checked out right now, but can you try
> replacing the last line above
>
>&require_config_file ($FOREIGN, 'depcomp');
>
> with the following hack
>
>local ($save_dir) = ($relative_dir);
>$relative_dir = '.';
>&require_config_file ($FOREIGN, 'depcomp');
>$relative_dir = $save_dir;
>
> - Hari
> --
> Raja R Harinath -- [EMAIL PROTECTED]
> "When all else fails, read the instructions." -- Cahn's Axiom
> "Our policy is, when in doubt, do the right thing." -- Roy L Ash
? automake/automake-1.4a.tar.gz
Index: automake/Makefile.in
===
RCS file: /cvs/automake/automake/Makefile.in,v
retrieving revision 1.240
diff -u -r1.240 Makefile.in
--- Makefile.in 2000/11/18 23:58:24 1.240
+++ Makefile.in 2000/12/04 23:25:35
@@ -1,6 +1,7 @@
# Makefile.in generated automatically by automake 1.4a from Makefile.am
-# Copyright (C) 1994, 1995-9, 2000 Free Software Foundation, Inc.
+# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000
+# Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
@@ -314,6 +315,7 @@
rm -f $$i-[0-9]*; \
fi; \
done
+
install-dist_pkgdataDATA: $(dist_pkgdata_DATA)
@$(NORMAL_INSTALL)
Index: automake/automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.803
diff -u -r1.803 automake.in
--- automake.in 2000/11/26 01:39:48 1.803
+++ automake.in 2000/12/04 23:25:39
@@ -3042,22 +3042,17 @@
local ($config_aux_dir_specified) = ($config_aux_dir ne '.'
&& $config_aux_dir ne '');
- # Set $require_file_found{'depcomp'} if the depcomp file exists,
- # before calling require_config_file on `depcomp'. This makes
- # require_file_internal skip its buggy existence test that would
- # make automake fail (with `required file `lib/depcomp' not found')
- # when AC_CONFIG_AUX_DIR is not set. See tests/subdir4.test.
- local ($depcomp_dir) = ($config_aux_dir_specified ? $config_aux_dir
- : '.');
- $require_file_found{'depcomp'} = 1 if -f "$depcomp_dir/depcomp";
-
# Set location of depcomp.
local ($prefix) = ($config_aux_dir_specified ? $config_aux_dir
: '$(top_srcdir)');
&define_variable ('depcomp', "\$(SHELL) $prefix/depcomp");
+ # set $relative_dir so depcomp gets installed in $top_srcdir
+ local ($save_dir) = ($rela
bug: depcomp misplaced
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):
# Set location of depcomp.
local ($prefix) = ($config_aux_dir_specified ? $config_aux_dir
: '$(top_srcdir)');
&define_variable ('depcomp', "\$(SHELL) $prefix/depcomp");
&require_config_file ($FOREIGN, 'depcomp');
I'm not sure what the complete solution is, but it looks like
handle_dependencies isn't called until the first C file is encountered,
at which point &require_config_file adds depcomp to '.' (which could be
a subdir of $(top_srcdir)), ignoring the fact that it just defined the
depcomp variable to '$(top_srcdir)/depcomp'.
My workaround was to copy depcomp into $(top_srcdir) myself and remove
the other copies. After that everything worked like I thought it
should. From my scan of the code, it looks like using the
AC_CONFIG_AUX_DIR macro in configure.in might also make things work, but
I never tested that theory.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
Computer Lie #1: You'll never use all that disk space.
