[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable
From: |
Stefano Lattarini |
Subject: |
bug#9026: [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'
>
> 3. ACDIR-APIVERSION
>
> 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)
4. ACDIR
5. ACDIR-APIVERSION
> > 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.
Regards,
Stefano
- bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable, Stefano Lattarini, 2011/09/19
- bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable, Paolo Bonzini, 2011/09/19
- bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable, Stefano Lattarini, 2011/09/20
- bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable, Paolo Bonzini, 2011/09/20
- bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable,
Stefano Lattarini <=
- bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable, Paolo Bonzini, 2011/09/20
- bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable, Stefano Lattarini, 2011/09/20
- bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable, Stefano Lattarini, 2011/09/20
- bug#9026: [PATCH] aclocal: handle ACLOCAL_PATH environment variable, Stefano Lattarini, 2011/09/24