Den 2010-09-08 21:29 skrev Ralf Wildenhues:
> Hello Peter,
>
> * Peter Rosin wrote on Sun, Sep 05, 2010 at 10:02:39PM CEST:
>> Subject: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.
>>
>> * libltdl/config/ltmain.m4sh (func_mode_link): Avoid calculating
>> the cammand line length if the name lister has @file support and
>
> s/cammand/command
> comma after support (otherwise the sentence is misleading).
>
>> always use the @file branch. This works around the fact that all
>> objects and archives still need to be transformed to toolchain
>> format for toolchains that does not support @file. At least for
>
> do not
>
>> toolchains that have @file support...
>
> s/\. At/, at/
> Please no ellipses in ChangeLog entries, thanks.
Oh, I'll try to stop pushing the dot button, it's a bit of a bad habit
of mine I think,,, :-)
> I guess I'm a bit put off by this patch in that it makes it harder on
> GNU/Linux to debug libtool by copying and pasting the commands that it
> outputs, because the response file will be invisible. On this system,
> there's no advantage as long as the command line is not too long.
Ah, that's true.
> So, the question is whether to replace the patch with one that changes
>
> - if test "$len" -lt "$max_cmd_len" || test "$max_cmd_len" -le
> -1; then
> + if { test "$len" -lt "$max_cmd_len" \
> + || test "$max_cmd_len" -le -1; } \
> + && $tool_conversion_not_needed_on_this_system; then
>
> WDYT?
That works for me. I take it that you intend that as some kind of
pseudo code, and that
test X"$to_tool_file_cmd" = Xfunc_convert_file_noop
would be appropriate for the real implementation? Or did you really
want the new variable?
Hmmm, but @file makes it harder than necessary to debug on MSYS, since
the automatic command line conversion make the n...@file branch work
there. And the @file branch is probably bad for performance on MSYS too,
since the manual forking conversion is so much slower than the
automatic command line conversion. I think some kind of lazy conversion
strategy -- like the one in 'compile' -- would be a worthwhile
optimization.
Cheers,
Peter
PS. I'm still running and rerunning and rerunning the testsuite to find
out how much 6/7 is covered (disheartening results by the looks of it).
