Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.

[Peter Rosin]

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 address@hidden 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).