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).