automake-patches
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]