Re: Site Macro Directory

[Akim Demaille]

> On Fri May 24 12:35 2002 +0200, Akim Demaille wrote:
> > | While working on this, I noticed that the current autom4te code
> > | reverses the order of the `-I' options before passing them to m4.  The
> > | documentation says:
> > | 
> > |   `--include=DIR'
> > |   `-I DIR'
> > |        Also look for input files in DIR.  Multiple invocations
> > |        accumulate.  Contrary to M4 but in agreement with common sense,
> > |        directories are browsed from last to first.
> > | 
> > | From my perspective, this behavior is extremely counter-intuitive.
> > | Every other tool that I know of that accepts a `-I' option (including
> > | gcc, GNU make, GNU m4, and perl) prepends the arguments to the search
> > | path in the order specified.  As a result, I was extremely surprised
> > | to discover that autoconf does the reverse.
> > 
> > Because the logic is to respect the last flag occurrence first for all
> > the other flags but this one.  Honestly, to me it is a serious bug in
> > all the other implementations.
> > 
> > And it *does* matter to autom4te, for instance because you do want
> > sometimes to say ``I want _my_ macros to be used first''.  So you
> > `autom4te -l autoconf -I .'.  But then, you want `.' to take precedence.
> 
> I completely agree that the directories specified in the `-I' options
> should be checked before the others, but I don't think that requires
> their order to be reversed.  

Actually, I'm always expecting the most recent option to be the first
obeyed, including -I.  ISTR I left -Ipath1:path2 to have path1 checked
before path2.  Also, this is heavily used when experimenting several
sets of amcros (i.e., 1. when developping Autoconf, and 2. when
running the test suite).

> Why doesn't autoconf simply read all the `-I' options in order and
> prepend the complete list to the search path?  That's what existing
> tools do; for an example, try this:
> 
>   perl -Ifoo -Ibar -Ibaz -e 'print join("\n", @INC) . "\n";'

Because autom4te is 100% based on options: there is no hard coded path
at all, it learns its library path by a series of -I.

> It seems to me that this behavior would be much more intuitive and
> wouldn't break anything.  What does everyone else think about this?

I'm sorry to see I'm minoritary wrt this :(  It seems to me that we
are just propagating something which should never have happened this
way.

> Anyway, I should have explicitly mentioned the `-I' directories in my
> summary of the search path.  Here's what it should look like:
> 
>   1. Directories specified with the `-I' option.
>   2. The current working directory ($top_srcdir).
>   3. Directories specified in the $AC_MACRO_PATH environment variable
>      (if set).
>   4. The system-wide site macro directory (set when autoconf is
>      installed).
> 
> Please let me know what you think.

I'd like to find a means to preserve the simplicity of autom4te and
autom4te.cfg.  Maybe an additional -I like option would suffice.  The
interface, as it is today, is extremely robust and always does what
the user (who knows how it works, agreed) expects.  I fear we would
lose this robustness.