Re: 89-stricter-vars.patch

[Tom Tromey]

Akim> use strict is almost happy, there remains one var causing
Akim> problems: require_file_found, which I did not fix (it'd be easy)
Akim> because there is a dirty hack for depcomp.  Tom, why does it
Akim> have that special handling?  It does not follow the regular
Akim> rules?

I don't know any more than what the comment says, and what
tests/subdir4.test does.

I think the idea is that if depcomp appears at the top level then it
should be found in the subdirs even in "weird" situations.

Akim> In particular, the way require_file_internal modifies
Akim> @require_file_paths frigthens me to death.
Akim> require_file_internal should be a pure function (well,
Akim> installing copies should be the only side effect), taking
Akim> require_file_paths as an argument, and returning the right path.
Akim> As is, it's hairy and incredibly fragile (most ypically, hecking
Akim> it when you're drunk breaks it :).

The require_file code has always been horrible.  I'm in favor of
almost any plan to clean it up.

As I recall the problem is that having automake follow the autoconf
logic for finding these files is hard.  That's especially true when
you consider that there are special cases.  Eg some people seem to
want to have mdate-sh and texinfo.tex in the directory with their
texinfo files, not in ac_config_aux_dir.

Akim> BTW, until mu drunkness drove me to remove all the work I had
Akim> done to uniformize the handling of $config_aux_dir, I had it
Akim> default to $(top_srcdir), and had good results.  Is there any
Akim> point in defaulting it to nothing and special casing it
Akim> everywhere it appears?

Akim> Also, what's the deep meaning of
Akim> my @config_aux_path = ('.', '..', '../..');
Akim> ?  What's special about ../.. and even .. ?  Anything to do with
Akim> $cygnus_mode?

This is to keep automake in line with how autoconf looks for these
files.

For instance consider libgcj, which is in the gcc tree.  libgcj wants
to use `../config.guess' because that lets us only have one
config.guess in the gcc tree, removes the burden of updating
config.guess from the libgcj developers, etc.  As it turns out libgcj
uses AC_CONFIG_AUX_DIR(..), but I don't think that is strictly
required by autoconf.  I think configure will still find it in `..'.

If we had automake complain that config.guess was not in `.' even
though autoconf would find it, that would generate bug reports.

I agree this sucks, but it seems like we're stuck with it.  A bad
decision was made in the early days of autoconf.

Akim> -       fgrep -v 'undef $/'; then \
Akim> +       fgrep -v 'undef $/' | \

Don't you mean `$$/'?

Akim> -    # Needs dynamic scopes.
Akim> -    local $relative_dir = '.';
Akim> +    # FIXME: Is this broken because it needs dynamic scopes.
Akim> +    # My tests seems to show it's not the case.
Akim> +    $relative_dir = '.';

The old code was ugly.  This is ugly too, since it relies on the fact
that $relative_dir isn't set for real until after this function
returns.  I'd prefer a comment explaining this.  (Actually, I'd prefer
to have all the require_file code cleaned up :-)

This patch is ok.

Tom