[Top][All Lists]

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

Re: Overriding LN_S

From: Peter Rosin
Subject: Re: Overriding LN_S
Date: Mon, 10 Jan 2011 13:19:29 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20101207 Thunderbird/3.1.7

Den 2010-10-21 12:02 skrev Paolo Bonzini:
> On 10/18/2010 10:07 AM, Peter Rosin wrote:
>>> So, your patch needs more work, either in autoconf.texi (documenting
>>> that LN_S needs to be set in the environment rather than on the
>>> configure command line) or we need to think or some other way to
>>> fixup the _AS_LN_S_PREPARE result after command-line parsing, or
>>> restructure the code otherwise.
>> The below one-liner makes the tests pass.  I don't know if we should
>> perhaps use test "${LN_S+set}" = set instead, and I don't know if it's
>> ok to clobber as_ln_s from "the outside" like this.  I also suppose
>> there's an area of the configure script that will run with unexpected
>> outcome of any AS_LN_S([foo], [bar]) macros (between the _AS_LN_S_PREPARE
>> expansion and AC_PROG_LN_S, at least as long as _AS_LN_S_PREPARE is
>> expanded first but that seems pretty hard to change).
> Something like the attached...  still requires writing ChangeLogs.


I got hit by this LN_S mess again recently, and wasted valuable time
waiting for results that were simply plain wrong.  Twice.  So I'm
wondering if this is going anywhere?  Am I expected to pick up the
pieces from this thread and submit a new patch?  What pieces should
I pick in that case?


reply via email to

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