Re: New auxiliary archive script

[Ralf Wildenhues]

* 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