Re: git log -> changelog
On 09/02/2010 03:16 PM, Charles Wilson wrote: On 9/2/2010 5:08 PM, Eric Blake wrote: On 09/02/2010 03:00 PM, Charles Wilson wrote: Two people worked on a single patch, or someone submitted it, and then one of the people with commit access modified the patch slightly. The GCS says you should do this, in the ChangeLog: === 2010-09-02 John Original Submitter<...> Steve Committer Rewrite<...> <<<=== can't do this Well, if you go by git's Signed-off-by tags as a way of generating those lines, it would be possible. Ah, but then how do you distinguish between a chain of Signed-off-by labels -- as in the Linux kernel, where various subsystem maintainers also have to sign off on patches, in the sense of "I certify that this is OK, and it has proper approvals, and has been reviewed, (FSF: and the author has a copyright assignment). vs. "and I modified the actual contents of the patch a little bit" The git pages are clear that S-O-B has project-dependent interpretation. Coreutils currently doesn't even use it (the only people with commit privileges to the master coreutils.git have FSF copyright, and it is assumed that they are each trustworthy enough to do due diligence in verifying that patches from other contributors meet copyright rules, without relying on any markup in the commit message itself). But if we wanted, we could adopt a policy that S-O-B on GNU projects using the gitlog-to-changelog conversion implies (partial) authorship, above and beyond the --author. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: git log -> changelog
On 9/2/2010 5:08 PM, Eric Blake wrote: > On 09/02/2010 03:00 PM, Charles Wilson wrote: >> Two people worked on a single patch, or someone submitted it, and then >> one of the people with commit access modified the patch slightly. The >> GCS says you should do this, in the ChangeLog: >> >> === >> 2010-09-02 John Original Submitter<...> >> Steve Committer Rewrite<...><<<=== can't do this > > Well, if you go by git's Signed-off-by tags as a way of generating those > lines, it would be possible. Ah, but then how do you distinguish between a chain of Signed-off-by labels -- as in the Linux kernel, where various subsystem maintainers also have to sign off on patches, in the sense of "I certify that this is OK, and it has proper approvals, and has been reviewed, (FSF: and the author has a copyright assignment). vs. "and I modified the actual contents of the patch a little bit" -- Chuck
git log -> changelog [was: [PATCH] Path conversion documentation]
[adding bug-gnulib] On 09/02/2010 03:00 PM, Charles Wilson wrote: IF we want to use gitlog to create the ChangeLog, then either of these is fine with me. However, see below. iii) fix the gitlog entries -- if that's even viable? I don't think (iii) will work. You can play all sorts of games with filter-branch, but...I managed to screw up three different git clones before I gave that up as a bad idea (I was trying to fix the author of a commit that was not the final entry). Recent git has added the notion of annotations; we could use a specific annotation namespace for replacement ChangeLog messages to be used for any commit where we typo'd the original commit log (or left out credit for a contributor, etc.). But since Jim was the one that developed the gitlog to changelog conversion tool, he's more familiar with what it would take, and whether it even makes sense to require a new enough git version to exploit commit annotations as a means of fixing ChangeLog entries. Comments? It does seem like gitlog and ChangeLog duplicate the same info, so it would definitely be nice to reduce dvlpr workload. However, I have noticed that you /just can't/ do the following -- which is actually required by the GCS: Two people worked on a single patch, or someone submitted it, and then one of the people with commit access modified the patch slightly. The GCS says you should do this, in the ChangeLog: === 2010-09-02 John Original Submitter<...> Steve Committer Rewrite<...><<<=== can't do this Well, if you go by git's Signed-off-by tags as a way of generating those lines, it would be possible. Also, this would be an argument where annotations could serve to fill in the gap. * file (func): comment Signed-off-by: Steve Committer Rewrite<...> === Also, for trivial commits without a copyright assignment, the GCS says you should do this: === 2010-09-02 Sally No Assignment<...> (tiny change) Again, something that annotations could cover. * file (func): comment Signed-off-by: Mark Committer<...> === Now, MAYBE the committer can do that by munging the --author='...'; I've never tried and I'm not sure how thoroughly git checks the --author argument. You can munge anything before the email, but can't add (tiny change) afterwards (in other words, git hard-codes the email address to be last). I'd rather not munge --author, since 'git shortlog' would be noticeably worse with annotations like that. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [PATCH] Path conversion documentation
On 9/2/2010 3:05 AM, Gary V. Vaughan wrote: > On 2 Sep 2010, at 12:40, Charles Wilson wrote: >> 'Course, I notice that I screwed up the date in the ChangeLog. Could >> the next person to commit a change to that file, please fix it? >> >> -2010-09-31 ... >> +2010-09-01 ... > > Might be unnecessary... Well, we aren't yet using your use-gnulib branch, and right now the ChangeLog contains an inaccurate date. So, since I'm *sure* somebody is going to commit something to master between now and the release... > > In my use-gnulib branch, I'm wondering whether to incorporate > gitlog-to-changelog, and have it generate the current year's ChangeLog at > distribution time. However the first few months of the year don't have > suitable gitlog's to convert nicely. I can think of a few options: > > i) wait until next year >ii) post process the output of gitlog-to-changelog for now IF we want to use gitlog to create the ChangeLog, then either of these is fine with me. However, see below. > iii) fix the gitlog entries -- if that's even viable? I don't think (iii) will work. You can play all sorts of games with filter-branch, but...I managed to screw up three different git clones before I gave that up as a bad idea (I was trying to fix the author of a commit that was not the final entry). > Comments? It does seem like gitlog and ChangeLog duplicate the same info, so it would definitely be nice to reduce dvlpr workload. However, I have noticed that you /just can't/ do the following -- which is actually required by the GCS: Two people worked on a single patch, or someone submitted it, and then one of the people with commit access modified the patch slightly. The GCS says you should do this, in the ChangeLog: === 2010-09-02 John Original Submitter <...> Steve Committer Rewrite <...> <<<=== can't do this * file (func): comment Signed-off-by: Steve Committer Rewrite <...> === Also, for trivial commits without a copyright assignment, the GCS says you should do this: === 2010-09-02 Sally No Assignment <...> (tiny change) * file (func): comment Signed-off-by: Mark Committer <...> === Now, MAYBE the committer can do that by munging the --author='...'; I've never tried and I'm not sure how thoroughly git checks the --author argument. -- Chuck
tests: avoid spurious test failure due to library mode on HP-UX.
http://autobuild.josefsson.org/libtool/log-201008291316534087000.txt | ../../libtool/tests/help.at:164: $orig_LIBTOOL --mode=install cp liba.la libb.la $libdir | stderr: | cp: cannot create /tmp/lt/build-hppa2.0w-hp-hpux11.11/tests/testsuite.dir/023/inst/lib/liba.sl.0.0: Permission denied | stdout: | libtool: install: cp .libs/liba.sl.0.0 /tmp/lt/build-hppa2.0w-hp-hpux11.11/tests/testsuite.dir/023/inst/lib/liba.sl.0.0 | ../../libtool/tests/help.at:164: exit code was 1, expected 0 | 23. help.at:97: 23. debug tracing (help.at:97): FAILED (help.at:164) This is because cp won't overwrite a file with mode 555; but install-sh will. We specifically use mode 555 on HP-UX because missing execute permissions cause library loading to fail or be very slow, and the installed system libraries al seem to not have w bits set either (otherwise I would have suggested using 755 instead). I should apologize for slightly messing up wrt. git log cleanliness in that I introduced a merge on master because I didn't rebase on top of Charles' last patch before merging master to the lto branch. At least, this way an eventual merge of the lto branch should be trivial. Cheers, Ralf tests: avoid spurious test failure due to library mode on HP-UX. * tests/help.at (debug tracing): Use $lt_INSTALL not cp for install mode, the latter will not overwrite an existing library with mode 555. diff --git a/tests/help.at b/tests/help.at index c4eaa87..0b60a0d 100644 --- a/tests/help.at +++ b/tests/help.at @@ -161,7 +161,7 @@ for trace in '' --debug; do # Hypothesis: --debug should be passed to relink mode if (and only if) # it was passed at link mode. - AT_CHECK([$orig_LIBTOOL --mode=install cp liba.la libb.la $libdir], + AT_CHECK([$orig_LIBTOOL --mode=install $lt_INSTALL liba.la libb.la $libdir], [], [stdout], [stderr]) if grep ': relinking ' stdout stderr; then if test "X$trace" = X--debug; then
Re: [PATCH 4/7] Use func_to_tool_file instead of fix_srcfile_path.
* 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
Re: Make ar-lib support backslashed files in archives. (was [PATCH 0/7] Support for toolchains that are not $host-native.)
On Thursday 02 September 2010, Peter Rosin wrote: > It is actually a bug in ar-lib. When you issue > .../ar-lib lib x foo.lib > it runs this loop: > > $AR -NOLOGO -LIST "$archive" | while read member > do > $AR -NOLOGO -EXTRACT:"$member" "$archive" || exit $? > done > > (with archive=foo.lib) > > and that reads members from the archive but breaks if there's a > backslash in one of the members. This works much better: > > $AR -NOLOGO -LIST "$archive" | sed -e 's/\\//g' | while read member; > do > $AR -NOLOGO -EXTRACT:"$member" "$archive" || exit $? > done Given that Solaris 10 /bin/sh, /usr/xpg4/bin/sh and /bin/ksh do not support (or fail to honour) the `-r' option of the read builtin (bummer!), your fix seems the best one to me. But wait for Ralf's review, as he might know better. Regards, Stefano
Re: [PATCH 0/7] Support for toolchains that are not $host-native.
Den 2010-09-02 16:08 skrev Peter Rosin: > Den 2010-09-02 16:02 skrev Charles Wilson: >> On 9/2/2010 9:06 AM, Peter Rosin wrote: >>> However, my previous suggestion with a naive_slashify instead of >>> naive_backslashify doesn't work either since MSYS turns @c:/foobar into >>> @c;c:\msys\1.0\foobar (or something similar, that was from memory) which >>> we must avoid at all cost. cygpath -m (instead of -w) is fine on Cygwin >>> though since Cygwin doesn't clobber @c:/foobar "for us". >>> >>> Maybe we can work around this by sanitizing the input files in ar-lib, >>> but that seems a bit horrible to me... I'll see if I can fix this >>> somehow. Suggestions welcome. >> >> Actually, I think MSYS's heuristic for determining whether an argument >> contains a path -- and whether that path is already a dos-style one -- >> should be improved so that args which match the regex >> '^...@[[:alpha:]]:[/\]' are understood as dos-style abspaths. >> >> I'll look into that. > > That would be nice indeed. > >> Oh, wait. >> >> We'd also need to add exceptions for all of MSVC's command switches, >> which prohibit spaces between the switch and that path: -FoC:/bob/, >> -FeD:/fred, etc. Ick. >> >> I dunno if that's worth the effort -- or if it would even be accepted. >> After all, MSYS's reason for existence is to support MinGW, not MSVC... >> I could justify adding the '@' heuristic, because MinGW ar can use it, >> but the rest... >> >> What do you think, Peter? > > The rest is handled by the compile script (in automake) in my case... Ahh, now I see what you mean here. If we have already transformed -o /bob/... into -FoC:/bob/... and then MSYS thinks it's a path and in turn makes it into -Foc;c:\msys\1.0\bob\..., then we're really up shit creek... But luckily, MSYS apparently does not handle -FoC:/bob/... the same way it handles @C:/bob/..., so we are safe... I have verified that "cl -c -FoC:/foo.obj C:/foo.c" does indeed create a c:/foo.obj file. Cheers, Peter
Make ar-lib support backslashed files in archives. (was [PATCH 0/7] Support for toolchains that are not $host-native.)
Hi! [Automakers, this is from the libtool-patches list...] Den 2010-09-02 15:06 skrev Peter Rosin: > 112: Test 24 33 34 45 47 99 100 are "new" failures with low max_cmd_len > and I think the reason is that the file name conversion adds escapes for > the backslashes. I.e. .libs/a1.obj -> .libs\\a1.obj when in this case > .libs\a1.obj is desired. 25 also fails earlier, probably due to the same > thing. However, my previous suggestion with a naive_slashify instead of > naive_backslashify doesn't work either since MSYS turns @c:/foobar into > @c;c:\msys\1.0\foobar (or something similar, that was from memory) which > we must avoid at all cost. cygpath -m (instead of -w) is fine on Cygwin > though since Cygwin doesn't clobber @c:/foobar "for us". > > Maybe we can work around this by sanitizing the input files in ar-lib, > but that seems a bit horrible to me... I'll see if I can fix this > somehow. Suggestions welcome. It is actually a bug in ar-lib. When you issue .../ar-lib lib x foo.lib it runs this loop: $AR -NOLOGO -LIST "$archive" | while read member do $AR -NOLOGO -EXTRACT:"$member" "$archive" || exit $? done (with archive=foo.lib) and that reads members from the archive but breaks if there's a backslash in one of the members. This works much better: $AR -NOLOGO -LIST "$archive" | sed -e 's/\\//g' | while read member do $AR -NOLOGO -EXTRACT:"$member" "$archive" || exit $? done Ok for the msvc branch? The code added to the test fails with old ar-lib and works with the change. Cheers, Peter >From 63daad5a46cecf88c168e20febdec7d53568c111 Mon Sep 17 00:00:00 2001 From: Peter Rosin Date: Thu, 2 Sep 2010 16:46:14 +0200 Subject: [PATCH] Make ar-lib support backslashed files in archives. * lib/ar-lib: If an archive member contains a backslash, make sure it is escaped when the archive member is extracted. * lib/ar-lib.test: Test the above. Signed-off-by: Peter Rosin --- ChangeLog |7 +++ lib/ar-lib|2 +- tests/ar-lib.test |7 +++ 3 files changed, 15 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5d80edb..aaebf94 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2010-09-02 Peter Rosin + + Make ar-lib support backslashed files in archives. + * lib/ar-lib: If an archive member contains a backslash, make sure + it is escaped when the archive member is extracted. + * lib/ar-lib.test: Test the above. + 2010-08-31 Peter Rosin Do file name conversion for object files in the compile wrapper. diff --git a/lib/ar-lib b/lib/ar-lib index ef03430..0f0a31b 100755 --- a/lib/ar-lib +++ b/lib/ar-lib @@ -219,7 +219,7 @@ elif test -n "$extract"; then esac done else -$AR -NOLOGO -LIST "$archive" | while read member +$AR -NOLOGO -LIST "$archive" | sed -e 's/\\//g' | while read member do $AR -NOLOGO -EXTRACT:"$member" "$archive" || exit $? done diff --git a/tests/ar-lib.test b/tests/ar-lib.test index d418c21..4759b65 100755 --- a/tests/ar-lib.test +++ b/tests/ar-lib.test @@ -26,6 +26,8 @@ cat >lib <<'END' #! /bin/sh if test x"$2" = x-LIST -a $3 = fake.lib; then echo fake.obj +elif test x"$2" = x-LIST -a $3 = fake2.lib; then + echo dir\\fake2.obj else echo "lib $@" fi @@ -76,4 +78,9 @@ test x"$opts" = x"lib -NOLOGO -EXTRACT:foo.obj foo.lib" opts=`./ar-lib ./lib -lib -LTCG x foo.lib foo.obj` test x"$opts" = x"lib -lib -LTCG -NOLOGO -EXTRACT:foo.obj foo.lib" +# Check if ar-lib can extract backslashed members +touch fake2.lib +opts=`./ar-lib ./lib x fake2.lib` +test x"$opts" = x"lib -NOLOGO -EXTRACT:dir\\fake2.obj fake2.lib" + : -- 1.7.1
Re: [PATCH 0/7] Support for toolchains that are not $host-native.
Den 2010-09-02 16:02 skrev Charles Wilson: > On 9/2/2010 9:06 AM, Peter Rosin wrote: >> However, my previous suggestion with a naive_slashify instead of >> naive_backslashify doesn't work either since MSYS turns @c:/foobar into >> @c;c:\msys\1.0\foobar (or something similar, that was from memory) which >> we must avoid at all cost. cygpath -m (instead of -w) is fine on Cygwin >> though since Cygwin doesn't clobber @c:/foobar "for us". >> >> Maybe we can work around this by sanitizing the input files in ar-lib, >> but that seems a bit horrible to me... I'll see if I can fix this >> somehow. Suggestions welcome. > > Actually, I think MSYS's heuristic for determining whether an argument > contains a path -- and whether that path is already a dos-style one -- > should be improved so that args which match the regex > '^...@[[:alpha:]]:[/\]' are understood as dos-style abspaths. > > I'll look into that. That would be nice indeed. > Oh, wait. > > We'd also need to add exceptions for all of MSVC's command switches, > which prohibit spaces between the switch and that path: -FoC:/bob/, > -FeD:/fred, etc. Ick. > > I dunno if that's worth the effort -- or if it would even be accepted. > After all, MSYS's reason for existence is to support MinGW, not MSVC... > I could justify adding the '@' heuristic, because MinGW ar can use it, > but the rest... > > What do you think, Peter? The rest is handled by the compile script (in automake) in my case... Cheers, Peter
Re: [PATCH 0/7] Support for toolchains that are not $host-native.
On 9/2/2010 9:06 AM, Peter Rosin wrote: > However, my previous suggestion with a naive_slashify instead of > naive_backslashify doesn't work either since MSYS turns @c:/foobar into > @c;c:\msys\1.0\foobar (or something similar, that was from memory) which > we must avoid at all cost. cygpath -m (instead of -w) is fine on Cygwin > though since Cygwin doesn't clobber @c:/foobar "for us". > > Maybe we can work around this by sanitizing the input files in ar-lib, > but that seems a bit horrible to me... I'll see if I can fix this > somehow. Suggestions welcome. Actually, I think MSYS's heuristic for determining whether an argument contains a path -- and whether that path is already a dos-style one -- should be improved so that args which match the regex '^...@[[:alpha:]]:[/\]' are understood as dos-style abspaths. I'll look into that. Oh, wait. We'd also need to add exceptions for all of MSVC's command switches, which prohibit spaces between the switch and that path: -FoC:/bob/, -FeD:/fred, etc. Ick. I dunno if that's worth the effort -- or if it would even be accepted. After all, MSYS's reason for existence is to support MinGW, not MSVC... I could justify adding the '@' heuristic, because MinGW ar can use it, but the rest... What do you think, Peter? -- Chuck
Re: [PATCH 0/7] Support for toolchains that are not $host-native.
Den 2010-09-01 22:30 skrev Peter Rosin: > Hi! > > I was going to hold off this until after I had run the testsuite one more > time with the latest fixes, but the recent message from Gary made me post > right away. By the Lay of Murphy, I'm sure I'll regret it... > > This series is a rebased and updated version of the patches posted in > http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00222.html > > I have reason to believe that these patches will make the testsuite > results cleaner for MinGW (gcc) on MSYS, MSVC on MSYS, MSVC on Cygwin > and have no impact on gcc on Cygwin. > > I will post details in a day of so when the testsuite has finished > running... I have made some notes after each testsuite excerpt. Testsuite results for gcc on Cygwin === configured with: ../libtool-msvc/configure ## --- ## ## GNU Libtool 2.2.11a test suite. ## ## --- ## Shell option parser generator. 1: short option splitting ok 2: enhanced shell short option splitting ok 3: long option splitting ok 4: XSI long option splitting ok 5: option appendingok 6: enhanced shell option appending ok Libtoolize operation. 7: libtoolize macro installation ok 8: libtoolize macro directory mismatch error ok 9: libtoolize macro serial update ok 10: libtoolize config files serial update ok 11: diagnose missing LT_CONFIG_LTDL_DIR ok 12: copy ltdl.m4 with shared macro directoryok 13: correctly parse LTDL_INIT from configure.ac ok 14: diagnose missing LTDL_INIT invocation ok 15: upgrading verbatim style aclocal.m4 ok 16: verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIR ok 17: nonrecursive ltdl with AC_CONFIG_MACRO_DIR ok 18: subproject ltdl with non-shared directories ok 19: LIBTOOLIZE_OPTIONS ok 20: cleanup old installationok Testing libtool functions. 21: standard command line options ok 22: mode short-handsok 23: debug tracing ok 24: duplicate members in archive tests ok 25: duplicate convenience archive names ok 26: preserve duplicate convenience deps expected failure (duplicate_deps.at:72) 27: passing CC flags through libtoolok 28: passing CXX flags through libtool ok 29: passing F77 flags through libtool ok 30: passing FC flags through libtoolok 31: passing GCJ flags through libtool ok 32: inherited_linker_flags ok 33: C convenience archives ok 34: C++ convenience archivesok 35: F77 convenience archivesok 36: FC convenience archives ok 37: Java convenience archives FAILED (convenience.at:275) 38: Link order test ok 39: Link order of deplibs ok 40: Failure tests ok 41: shlibpath_overrides_runpath skipped (shlibpath.at:54) 42: Runpath in libtool library filesok 43: static linking flags for programs ok 44: ccache -all-static ok 45: Export test ok 46: sys_lib_search_path ok 47: indirect convenienceok 48: indirect uninstalledok 49: static library contains static library expected failure (archive-in-archive.at:56) 50: both of -o prog and -o prog$EXEEXT work ok 51: execute modeok 52: bindir compile checkok 53: bindir basic lib test ok 54: bindir install testsok 55: cwrapper for uninstalled executablesok 56: deplib in subdirok 57: inferred tagok 58: CXX inferred tagok 59: F77 inferred tagok 60: FC inferred tag ok 61: GCJ inferred tagok 62: localized compiler messages ok 63: nocase library search skipped (nocase.at:31) 64: Install tests ok 65: versioning ok DESTDIR tests 66: Simple DESTDIR install ok 67: DESTDIR with in-package deplibs ok Support for older m4 inter
Re: [PATCH] Path conversion documentation
On 2 Sep 2010, at 12:40, Charles Wilson wrote: > 'Course, I notice that I screwed up the date in the ChangeLog. Could > the next person to commit a change to that file, please fix it? > > -2010-09-31 ... > +2010-09-01 ... Might be unnecessary... In my use-gnulib branch, I'm wondering whether to incorporate gitlog-to-changelog, and have it generate the current year's ChangeLog at distribution time. However the first few months of the year don't have suitable gitlog's to convert nicely. I can think of a few options: i) wait until next year ii) post process the output of gitlog-to-changelog for now iii) fix the gitlog entries -- if that's even viable? Comments? Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part
Re: [PATCH 4/7] Use func_to_tool_file instead of fix_srcfile_path.
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 >> 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
