[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] aclocal: handle ACLOCAL_PATH environment variable

From: Stefano Lattarini
Subject: Re: [PATCH] aclocal: handle ACLOCAL_PATH environment variable
Date: Tue, 20 Sep 2011 14:09:07 +0200
User-agent: KMail/1.13.7 (Linux/2.6.30-2-686; KDE/4.6.5; i686; ; )

On Tuesday 20 September 2011, Paolo Bonzini wrote:
> On 09/20/2011 12:51 PM, Stefano Lattarini wrote:
> > >  Yes (and that's on purpose: ACLOCAL_PATH is typically used by a user
> > >  which has newer versions of libraries installed, so they need their
> > >  directories to override everything).
> >
> > Yes, this might be desirable.  But then, for consistency sake, shouldn't
> > we allow the .m4 files in the default system acdir and in the directories
> > added through a `dirlist' file to override the automake macros as well?
> Yeah, I think the problem is that in the normal search path (from 
> `aclocal -I /foo -I /bar'):
>    1. `/foo'
>    2. `/bar'
>    4. ACDIR
> The directories from dirlist and ACLOCAL_PATH should go after (3), 
> rather than after (4).
But this is what they currently do (see test `aclocal-path-precedence.test').

> Perhaps even after (2).
My opinion is that in this case the precedence resulting from this setup:

  $ echo /lst > ACDIR/dirlist
  $ ACLOCAL_PATH=/pth aclocal -I /inc

should become like this:

 1. /inc (-I)
 2. /pth ($ACLOCAL_PATH)
 3. /lst (dirlist)

> > I'm not sure about this, it has its pros and cons...  Anyway, if we decide
> > to go down this road, we should wait for 1.12, as the introduction of such
> > a backward-incompatibility, albeit limited, is inappropriate for a minor
> > release such as 1.11.2.
> You could certainly push your patch now and modify the behavior of both 
> dirlist and ACLOCAL_PATH in 1.12.
I agree.

> I doubt there are many dirlist users anyway,
Not sure about this...

> so the probability of regressions should be quite low.
But I'm pretty sure about this OTOH, since to experience a regresssion
the users should have redefined some automake macros in the .m4 files
in ACDIR (or in a dirlist-derived directory), *without expecting these
redefinitions to take precedence* over the ones in ACDIR-APIVERSION
-- and this is very very unlikely IMHO.

So I'll push the patch soonish (this evening or tomorrow); the backward
incompatible change in the order of the search path can be then
implemented in master later.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]