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

[Peter Rosin]

Den 2010-09-01 23:30 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Wed, Sep 01, 2010 at 10:33:59PM CEST:
>> From 16232cc7ddfc4bab981a2fa2d87757c68832b32e Mon Sep 17 00:00:00 2001
>> From: Peter Rosin <address@hidden>
>> Date: Sun, 29 Aug 2010 18:26:16 +0200
>> Subject: [PATCH 4/7] Use func_to_tool_file instead of fix_srcfile_path.
>>
>> * libltdl/config/ltmain.m4sh (func_mode_compile): Replace the
>> fix_srcfile_path hook with a call to func_to_tool_file.
>> * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin,mingw,pw32]
>> [cegcc]: Drop fix_srcfile_path.
> 
> Please ask google codesearch whether fix_srcfile_path is used by third
> party packages which expect it to be set inside the configure script.
> In case of doubt, we should keep the setting of it for compat reasons.

I used these search criteria:
fix_srcfile_path
-fix_srcfile_path=
-TAGVAR\(fix_srcfile_path,\ \$1\)
-TAGVAR\(\[fix_srcfile_path\],.*\)
-file:ltmain\.(m4sh|sh|in)
-file:ChangeLog
-file:\.texi
-file:libtool\.info

And got it down to a screenfull, with one prospect for a hit - a fuse port
for osx (at least that's what I'm guessing it is). But it turns out that
it is just a patch that includes a diff for ltmain.sh. I guess it should
be mentioned in NEWS if it's removed. However, I'm not desperate about this
patch as I'm saved by the compile script anyway. At least I think so? Maybe
we should just try to drop it and move all the new functions after
func_mode_compile as Chuck had them from the start? Regardless, we could
move all the path functions down and only keep the file name functions
where they are if that proves to be beneficial for performance as only the
file name functions are needed above func_mode_compile (and by this patch
only).

> The patch series is lacking libtool.texi updates.

I'll add something (and fix the nit noted by Check for 1/7) and repost
later. The testsuite is still running so I can't touch my tree yet.
(I know, I could just make a clone, but...)

> The changes to archive_cmds that introduce func_to_tool_file will make
> it impossible (right?) for users to use that command inside a configure

I suppose so.

> test.  I'm not sure whether that is a problem in practice -- we
> recommend using LT_OUTPUT and then using ./libtool, but a quick
> codesearch check shouldn't hurt.

I got it down to a few dozen hits with these search terms:
archive_cmds
-archive_cmds(=|_need_lc)
-file:ltconfig
-file:ltmain.(m4sh|sh|in)
-file:libtool.info
-file:ChangeLog
-file:/libtool$
-file:\.(html|texi|xml)$

And could not locate anything real there.

> 1/7 has a superfluous commented-out line in ltmain.

Oops, will kill them...

> 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/...)
It works just fine in the low max_cmd_len test though, which is kind
of funny behavior :-).

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.

Cheers,
Peter