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

[Ralf Wildenhues]

* Peter Rosin wrote on Thu, Sep 02, 2010 at 09:00:13AM CEST:
> Den 2010-09-01 23:30 skrev Ralf Wildenhues:
> >> * 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.

Yes please.  I'm fine with removal in that case.

> 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?

Strictly add-on optimization that should remain separate; but if you can
show that it's sufficient, I'm fine with going that way.

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

Again, I'm fine with this if it works and if moving the functions is
done in a separate commit that does nothing else.

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

Cool.  Thanks for tracking all that down.

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

> It works just fine in the low max_cmd_len test though, which is kind
> of funny behavior :-).

Now why's that?

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

Thanks,
Ralf