* Peter Rosin wrote on Thu, Aug 05, 2010 at 11:10:38AM CEST: > Den 2010-08-04 22:18 skrev Ralf Wildenhues: > >Now if you insist, then maybe we can just find another compromise name. > >Please set $me to the name and use that throughout, so at least a change > >is easily done. ;-) > > I'm perfectly fine with 'archive', so let's go back to that. I found only > one problematic project on codesearch, and that was an ancient version > of gimp (0.54, 1997?): > http://archive.debian.org/debian-archive/debian/dists/Debian-1.3.1/contrib/source/gimp_0.54.1.orig.tar.gz > A quick peek at more recent versions of gimp shows that they no longer have > any clashing archive script. But I don't know when it was actually removed > from from the gimp source. It does not appear to be there in gimp 2.4 from > a couple of years ago.
So let's use "archive" then. Thanks for the history digging. > Should the AM_PROG_AR macro perhaps be required when AC_PROG_RANLIB is > seen? Hmmm, but the ranlib macro is from autoconf so probably not... Oohh, I dunno. Please leave this to a separate patch anyway. (One really ugly but probably convenient way could be to just attach it to the beginning of AC_PROG_RANLIB at AM_INIT_AUTOMAKE expansion time. Not sure if that's TRT if Libtool is in the game, though.) > >I found a few nits, but nothing substantial, so if you can format your > >next iteration as git patch, and given testing, it can just go in. > > What branch should I base this on? master, maint or msvc? Doesn't matter. I will anyway cherry-pick it onto msvc which is currently at v1.11-157-gda15b99. > >>Members can be specified on separate lines in a file named with @<file>. > >Please use @FILE not @<file>; the capitalization is already meant to > >denote metasyntactic variables (as is done by info pages). > > I wanted to, but binutils ar has this in its --help: > @<file> - read options from <file> Hmm, but both 'ld --help' and 'nm --help' have @FILE Read options from FILE so I'm wondering whether @<file> was intentional or not. Might want to ask the binutils list about this (also, so they know we do these kinds of hacks). Or, just write a decent functionality test instead ... > >>if test -n "$delete"; then > >> if test ! -f "$orig_archive"; then > > > >Can it be a symbolic link or another non-regular file type? > >Won't $AR detect a non-existing file? > > I doubt that lib will work with anything but regular files. > What I'm trying to accomplish is that lib will recreate the > archive every time if you do > lib -out:foo.lib foo.obj > lib -out:foo.lib bar.obj > lib -out:foo.lib baz.obj > so that you end up with a foo.lib that only contains baz.obj. > You have to do this: > lib -out:foo.lib foo.obj > lib -out:foo.lib foo.lib bar.obj > lib -out:foo.lib foo.lib baz.obj > to create an archive that contains all three objects (unless > you create it all in one go of course). If foo.lib doesn't > exist, lib falls over if you use the latter syntax. So, you > have to know in advance if you are adding to an existing > archive or if you are creating a new one. > > Per POSIX, ar should print a diagnostic if it has to create > an archive and the c modifier isn't specified, so I just hooked > that into the existing test. OK, thanks. > >> $AR -NOLOGO -LIST "$archive" | while read member > >> do > >> func_file_conv "$member" > >> $AR -NOLOGO -EXTRACT:"$file" "$archive" > >Does lib have no way to just extract the whole archive? > > No. Come on, what do you expect? :-) Ohh. I'm sorry for you and all other w32 users. Cheers, Ralf