[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 4/7] Use func_to_tool_file instead of fix_srcfile_path.
From: |
Ralf Wildenhues |
Subject: |
Re: [PATCH 4/7] Use func_to_tool_file instead of fix_srcfile_path. |
Date: |
Thu, 2 Sep 2010 20:39:27 +0200 |
User-agent: |
Mutt/1.5.20 (2010-04-22) |
* 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
[PATCH 7/7] Prefer $NM @file over calculating the cmd line length., Peter Rosin, 2010/09/01
[PATCH 6/7] Convert file name to toolchain format when invoking $NM., Peter Rosin, 2010/09/01
[PATCH 5/7] Convert POSIX file names to toolchain format for MSVC, Peter Rosin, 2010/09/01
Re: [PATCH 0/7] Support for toolchains that are not $host-native., Peter Rosin, 2010/09/02
Make ar-lib support backslashed files in archives. (was [PATCH 0/7] Support for toolchains that are not $host-native.), Peter Rosin, 2010/09/02