Re: New auxiliary archive script

[Peter Rosin]

Den 2010-08-10 22:18 skrev Ralf Wildenhues:
>>> 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.

Ahh, now I see the problem...

> 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.

One thing to consider is that the compile script is triggered "by chance"
for MSVC. It is just a lucky coincidence that MSVC doesn't support -c -o,
so that the compile script can add that support and then tag on the other
needed crap. I think the Intel C compiler on Windows has a similar option
set as MSVC, so it can probably be handled in much the same way. But if
the Window PGI compiler needs a wrapper, I don't think it will be
triggered by the current implementation of AM_PROG_CC_C_O.

Maybe Christopher Hulbert can chime in here?

If people didn't like having 'compile' in their tarballs, there can be
only one reason, -c -o is supported by all the compilers they need. In
which case they have not previously needed MSVC, or have that covered by
other means, i.e. a separate build system. Maybe more projects will
move over to using an autotooled build system for MSVC, but that is far
from certain. For one thing, it's going to be slower than separately
maintained MSVC project files. But I hate separate build systems -- it
is bad enough to maintain one for a project -- and I (obviously) want to
do "configure; make" for MSVC.

But others are obviously entitled to their own opinion and *I* am not
going to force 'compile' and 'ar-lib' on them if loads of users don't
want them.

Anyway, I'm too biased to vote on this issue.

> (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).

It all comes down to if we want (1) or (2). I obviously find (2) very
appealing but as I stated above, I don't think this is my call.
Hasn't autotools lost quite a bit of market share to CMake because
it hasn't supported MSVC? On the other hand, CMake produces MSVC
project files, maybe that is seen as a killer feature?

> 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?

No it doesn't, ar-lib then thinks only 'link' is the program and
then tries to interpret '-lib' as ar actions -> boom.

> 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.

That seems like overkill to me, why shouldn't such a change be done
in upstreams libtool from the start? Do you worry about configure.ac
authors having to wait for a new libtool version to be released?

> 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)?

I will certainly try.

> 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
>      ])
>    ])
> 
> 

Looks much better than my version, I will borrow heavily for the
ar @FILE test...

Cheers,
Peter