Re: New auxiliary archive script

[Ralf Wildenhues]

* Peter Rosin wrote on Tue, Aug 10, 2010 at 09:01:29AM CEST:
> 'wrappar' did cross my mind, but that just looks like a funny accent :-)

Yes, that one is funny indeed, and another almost-palindrome.

> Den 2010-08-09 21:39 skrev Ralf Wildenhues:
> >Further I'm fixing the archive and the compile script to use ! not ^ for
> >shell pattern negation, and using $me also in the --help output.
> 
> I tested with $me in the --help output but didn't get it to work so I
> removed it. But your version works. Sigh...

The difference between a quoted and an unquoted here-document:

cat <<eof
$HOME sweet home.
eof
cat <<\eof
$HOME sweet home.
eof

> >Should there be a verbose/debug mode in which the scripts print the
> >command(s) that they invoke; or even do this by default?  This could
> >help debug user failures in the future.
> 
> Any extra output from "ar-lib lib t foo.lib" would break some uses,
> unless it was on stderr of course. Other actions are less critical,
> but you can always "bash -x" it, the script is smallish and output
> isn't hard to parse. But a debug mode would be nice all the same...

OK.  This is not too pressing.

> >Wrt. the AM_PROG_AR implementation, __oline__ is a real nono, as it
> >causes spurious diffs in generated configure scripts.  I'll propose
> >an updated version.
> 
> Oh, didn't know that. I look forward to it, since I reused some of the
> code for the @FILE feature check for archivers needed in libtool.

I didn't know either, until GCC developers complained enough about their
spurious configure diffs.  And more, __oline__ was invented only because
of buggy shells not coping correctly with $LINENO.  Luckily the uses
here are not a problem with nowadays shells.

OK, so here's what I got now, rewriting the macro to log better.  Two
issues: For one, it now uses AC_TRY_EVAL which is deprecated, but I
can't see a better Autoconf API to use ATM.

More importantly, I think it remains to decide the intended use
semantics, not just for 'ar-lib' but even more importantly also for
'compile':

1) Do we want to allow/require the developer to decide "I want to make
my package suitable for building with MSVC"?

2) Or do we even want MSVC support to be added onto existing packages by
default?

If (1), then currently, the required steps seem to be adding
  AM_PROG_CC_C_O
  AM_PROG_AR

to configure.ac.  This is probably the more flexible approach, but it
means that packages need updating.  Also, the naming of AM_PROG_CC_C_O
is a bit suboptimal in that case, maybe we should introduce a new macro
AM_PROG_CC_WRAP that is documented to wrap majorly incompatible
compilers like w32; internally, it would for now just call
AM_PROG_CC_C_O.

(There is also the possibility to use yet another Automake option, but
I'd prefer to avoid that.)


If (2), then we could for example tack the ar test onto Autoconf's
ranlib test:

  m4_define([AC_PROG_RANLIB],
  [AM_PROG_AR
   m4_defn([AC_PROG_RANLIB])
  ])

This seems quite hacky, and might sit at odds with some developers, esp.
for packages that can never run on w32 for unrelated reasons anyway.
Also, I'm not yet sure what to do with 'compile' in that case.
(Developers have complained a lot about suggesting AM_PROG_CC_C_O until
we moved the warning to -Wportability.)


Users that would like to write their configure.ac scripts to be portable
to Automake with or without this code, should write something like this
in case (1):

  # Use new macros if they are defined.
  m4_ifdef([AM_PROG_CC_WRAP],
           [AM_PROG_CC_WRAP],
           [AM_PROG_CC_C_O])
  m4_ifdef([AM_PROG_AR],
           [AM_PROG_AR])

and should ideally not have to change anything in the case of (2).


Interaction with Libtool:

With Libtool and in case (1), AM_PROG_AR should come before LT_INIT.
Then we should put in AC_BEFOREs to warn about misordering.
Also, we kind of lose the ability to detect within Libtool macros
whether $AR was set by the user.  This isn't a problem now, but I'm
not so sure it cannot become one in the future.  We'll see I guess.

With (2), we could then AC_REQUIRE AM_PROG_AR from _LT_CMD_OLD_ARCHIVE
if the former is defined (and keep the AC_CHECK_TOOLS([AR]) otherwise).
Remember that Libtool should remain usable without Automake.


Finally, does your wrapper work with 'link -lib' too?

Can we think of a situation in which it may be useful to have the
configure.ac author (rather than the user invoking configure) modify
the set of tools we try for $AR?  Then we should leave a macro argument
IF-FAILS for that purpose, defaulting to error.

Then, when we have all these sorted out: would you be willing to write
testsuite additions to cover as many of the semantics as possible
(warn about misordering, recommend AM_PROG_AR, use it without or with
Libtool, etc)?

Below is the meat of AM_PROG_AR that I have currently.

Thanks,
Ralf

AC_CACHE_CHECK([the archiver ($AR) interface], [am_cv_ar_interface],
  [am_cv_ar_interface="ar"
   AC_COMPILE_IFELSE([[int some_variable = 0;]],
     [am_ar_try='$AR cru libconftest.a conftest.$ac_objext'
      AC_TRY_EVAL([am_ar_try])
      if test "$ac_status" -eq 0; then
        am_cv_ar_interface=ar
      else
        am_ar_try='$AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext'
        AC_TRY_EVAL([am_ar_try])
        if test "$ac_status" -eq 0; then
          am_cv_ar_interface=lib
        else
          m4_default([$1],
            [AC_MSG_ERROR([could not determine $AR interface])])
        fi
      fi
      rm -f conftest.lib libconftest.a
     ])
   ])