[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New auxiliary archive script
From: |
Ralf Wildenhues |
Subject: |
Re: New auxiliary archive script |
Date: |
Sun, 1 Aug 2010 20:06:23 +0200 |
User-agent: |
Mutt/1.5.20 (2010-04-22) |
Hi Peter,
* Peter Rosin wrote on Sun, Aug 01, 2010 at 06:54:57PM CEST:
> Now we need a something similar for the MS archiver (lib.exe)
Right.
> As it happens, binutils ar does not work as well as lib, MSVC
> sometimes has problems with the archives produced by ar. I
> know that I have stated otherwise recently, but I was wrong.
> The "odd" cases drowned in other failures since I was testing
> without most of the MSVC patches applied to libtool and I
> expected it to be a all or nothing deal. My bad.
No worries; please make a note to eventually report to the binutils
people though.
> FWIW, I get decent results with the below archive script and
> configuring with AR="/path/to/archive lib"
>
> The script still needs @<file>-support, in order to make it
> possible for libtool to avoid falling back to "-r -o"
> piecewise linking when the command line gets long, so that's
> a TODO, and the options handling could be better in order to
> better support more than just the very minimal ar features.
> It also needs the file conversion stuff from the compile
> script in order to support absolute file names. So, far from
> perfect...
>
> Would it be possible to include this new auxiliary script and
> a macro similar to the one that triggers the use of the compile
> script?
Yes, in principle: when them bugs are fixed. Would you be willing to
rewrite the script so it
- has the blurb header similar to 'compile',
- half-way decent option handling (doesn't barf on "shift" if given too
few options, diagnoses unknown options, treats contents of ARFLAGS as
options not members, etc.)
- prints error messages on stderr and exits nonzero then,
I wonder whether we can and should call it 'archive', or whether that
would clash with user file names in case they don't use
AC_CONFIG_AUX_DIR. OTOH, a script named 'ar' may not be installable
anywhere due to the ar binary already there. Thoughts?
Wrt. introducing a macro to set $AR, let's call it AM_PROG_AR, yes,
that's easy to add as well, but will require developer adjustment of her
configure.ac to have, and we need to coordinate with Libtool. Or we
could call it straight from AM_INIT_AUTOMAKE, hmm. For now a viable
workaround is to just
make AR=/path/to/archive
or, if Libtool is in the game,
configure AR=...
> AR=$1
> shift
> action=$1
> shift
> archive=$1
> shift
> members=$@
This doesn't work in general. Just keep using "$@" below in place of
$members (after extracting other flags).
> case $action in
> cru)
> $AR -NOLOGO -OUT:"$archive" $members
Some users may have hand-written ar calls with other flags, e.g.,
'ar r', or other combinations. Any chance we can help them, too?
For actual applicability, it is sufficient if you provide a working
script, post testsuite results with it in place (you might want to
MAKE='make AR=...'
in order to force-test it), NEWS and doc blurb, but no need for changes
to automake.in in the first iteration.
Thanks!
Ralf
- Re: pr-msvc-support merge, Ralf Wildenhues, 2010/08/01
- Re: New auxiliary archive script, Peter Rosin, 2010/08/05
- Re: New auxiliary archive script, Ralf Wildenhues, 2010/08/06
- Re: New auxiliary archive script, Peter Rosin, 2010/08/06
- cond5.test spurious failure (was: New auxiliary archive script), Stefano Lattarini, 2010/08/06