[Top][All Lists]

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

Re: Overriding LN_S

From: Eric Blake
Subject: Re: Overriding LN_S
Date: Thu, 02 Sep 2010 14:47:59 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100806 Fedora/3.1.2-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.2

On 09/02/2010 02:43 PM, Ralf Wildenhues wrote:
* Peter Rosin wrote on Thu, Sep 02, 2010 at 09:45:13PM CEST:
Den 2010-09-02 21:32 skrev Ralf Wildenhues:
* Peter Rosin wrote on Thu, Sep 02, 2010 at 09:18:29PM CEST:
I also want this to
propagate to recursive autoconf invocations, so it is not
sufficient to manually edit the generated configure script.

You mean recursive configure invocations?

No, I meant that some libtool tests invoke autoconf, and then configures
the result, e.g. libtool/tests/
If I hack up my top level configure to go with LN_S="cp -p", that will
not matter when the testsuite gets to, since it will
reset LN_S to "ln -s". At least I think it will, I haven't actually

Well, we /should/ fix Autoconf to allow overriding, and at that point,
you should be able to override globally with export LN_S=...
(though I'm not sure if LN_S will be the variable to set, that's not in
the m4sh name space).

Well, it's no different than offering overrides for CC, GREP, and other tool names outside the m4sh name space. I think the idea of allowing a pre-existing $LN_S from the user's environment take precedence makes total sense.

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library

reply via email to

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