[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:1.9.2.13) 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.
Ping.
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?
Cheers,
Peter
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Overriding LN_S,
Peter Rosin <=