Re: RFC: 59-autom4te-cfg.patch

[Akim Demaille]

I'm applying this patch, but I am still expecting some feedback.

----------------------------------------------------------------------

I now consider Autotest is really usable: its users no longer need to
deal with hard coded paths etc.  I am not willing to open autom4te.cfg
to users yet, but I think we should do it sooner or later.  For
instance, Alexandre Lutz once told me it'd be a good thing to specify,
on a per project basis, additional trace preselections.  We can bet
that Automake too will need to trace more that what I listed below.
And it would be a pity to have to wait two or more runs to have the
trace cache reach its equilibrium.

So what is needed is a means to *extend* a language with additional
flags.  Something like $top_srcdir/autom4te.cfg seems fine.  Does it?

Similarly, ~/.autom4te.cfg seems quite logical.  OTOH, this might be
the beginning of a new sort of troubles...

There is one dirty thing that crept in here: the CLI options are
processed *after* the language options, which is of course the right
thing.  But there is one option which will bite us: --include.  I've
personally always considered it a bug in most tools that --include be
processed in the order it has been given.  Based on the high level
rule that the latest options always win, I think path walks should
always be performed in the reversed order of --includes.

In autom4te, I didn't do that because at first I wanted to stick to
GNU M4's own path walk.

Now that we use this scheme, we have two possibilities:

1. ask me to put some magic especially for the include path so that
   the user wins, but still reports the include path forwardly.

2. let's implement backward path walks.


You'll have to give me strong arguments in favor of 1 if you really
prefer this.  I'll soon implement 2.

Oh, BTW, this will certainly be yet a problem with make check: chances
are high that if you have some 2.52c installed, then make check will
chose the installed files instead of those in $build...  It works for
me, but hey, my installed 2.52c is fairly recent :)


Oh, also, distcheck is broken, for a simple reason, but yet I'm unsure
how to fix this properly.  It is related to the usual problem src vs
build.  Currently autom4te needs to find Struct.pm in src, and
autom4te.cfg in build, but has only a single relocation envvar:
AC_MACRODIR.  I'm not sure what to do, but there are many means to
work around this, so I'm not afraid.