Hi! Ok, let's take a step back. This is no longer really merging work from the branch, so since A) using MS lib as archiver isn't essential for MSVC support (at least I don't think so, I can't remember any case where binutils ar hasn't worked for me, but ar creates archives that are different so I don't really like the situation) and B) by the looks of it it will have little to do with patching libtool anyway, I think it might be better to leave the archiver work behind for a bit.
Some points: By bringing a standalone script to the automake list that will (at the moment, and for the foreseeable future) only be of use if you want to use MS lib as archiver, but will still add another file to "all" packages, I feel that there is a risk that the benefit will be deemed too small when compared to the cost. ltmain is already large and a few extra lines will not be noticed by that many people. If another funky archiver is found, which will need wrapping, the needed "defunkying" should go into the same standalone script, anything else would be a failure from my pov. But then you end up with the problem Ralf mentioned (how to communicate from configure to the wrapper how the wrapper should behave). That problem is easily solved if the wrapper lives inside the libtool script. Similarly, since we need to teach libtool how to convert posix $build paths to $host paths anyway, if the wrapper lives in libtool we get the infrastructure for that for free when it's time to fix this for lib.exe. If the wrapper is standalone, it will need to figure these things out on every invocation (probably doing a bunch of painful forks) or it will need help from somewhere (i.e. configure via make à la depcomp). The above may sound as if I'm opposed to moving the script to automake, but I'm not. I'm mostly afraid of the script ending up where the cccl script - or should I say script_s_ - ended up. The good thing with a standalone script is that it is usable w/o some/all autotools. Having the script work w/o autoconf/automake is not terribly important, so falling back to the depcomp variable passing scheme when something is too painful to figure out at runtime is workable, methinks. Attaching a very rough first cut, but I don't intend to work on this at the moment as explained at the top. I'll post a mail addressing the next patch on the branch soonish instead. Cheers, Peter
#! /bin/sh case $1 in '') echo "$0: No command. Try \`$0 --help' for more information." 1>&2 exit 1; ;; -h | --h*) cat <<\EOF Usage: ar [--help] [--version] PROGRAM ACTION ARCHIVE [MEMBER...] EOF exit $? ;; -v | --v*) echo "ar v0.0" exit $? ;; esac AR=$1 shift action=$1 shift archive=$1 shift members=$@ test -z "$action" && echo "you must specify an action" test -z "$archive" && echo "you must specify an archive" case $action in cru) $AR -NOLOGO -OUT:"$archive" $members ;; x) $AR -NOLOGO -LIST:"$archive" | while read member do $AR -NOLOGO -EXTRACT:"$member" "$archive" done ;; t) $AR -NOLOGO -LIST:"$archive" ;; *) echo "bad archive action, either cru, x or t" ;; esac
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool