Re: [PATCH 4/7] Use func_to_tool_file instead of fix_srcfile_path.

[Peter Rosin]

Den 2010-09-02 20:39 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Thu, Sep 02, 2010 at 09:00:13AM CEST:
>> Den 2010-09-01 23:30 skrev Ralf Wildenhues:
>>> I haven't looked at the patch series in detail yet, but 1-6 look fairly
>>> reasonable otherwise.  7 looks risky because of the logic around there;
>>> also, the nm @file test isn't a real feature test.  Also, I just noticed
>>> that nm_file_list_spec isn't always initialized properly.
>>
>> Without 7/7, you get into trouble when using MSVC from Cygwin with
>> absolute file names, since $NM (i.e. "dumpbin -symbols") will not find
>> any symbols due to not being able to locate the requested file
>> (i.e. /some/cygwin/file-name.obj instead of C:/cygwin/some/cygwin/...)
> 
> Oh, I didn't mean to shoot down 7/7, I meant that 7/7 is the patch that
> I would like to look at in more detail before deciding.  The patch will
> change the ltmain execution path on several systems.

I'm just saying that my priorities are:
1. GNU
2. MSVC on MSYS
3. MSVC on Cygwin

Others may swap 2 and 3, but it is hard to make a case for demoting GNU
from the top spot. Anyway, in the beginning of this patch series there
are fixes for GNU, in the middle there are fixes for MSVC, but 7/7 is
only needed for (my) priority 3. All I'm saying is that while 7/7 is
nice, it isn't top priority. I'm fine with waiting a bit with it if you
need more time to digest it.

>> It works just fine in the low max_cmd_len test though, which is kind
>> of funny behavior :-).
> 
> Now why's that?

Because with low max_cmd_len you always take the (working) @file branch
when extracting symbols.

>> When using MSVC on MSYS you don't need 7/7, since you're saved by the
>> MSYS file name conversion on the command line.
> 
> Ah, ok.

Cheers,
Peter