Re: New auxiliary archive script

[Christopher Hulbert]

On Wed, Aug 11, 2010 at 10:12 AM, Peter Rosin <address@hidden> wrote:
> 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?

I have not used the compiler wrapper before. I certainly was able to
get the Windows PGI compilers to work. They conveniently support -c,
-o, -L, and -l. I only wish Intel would have been nice enough to do
that since they have non-Windows compilers.

Then again, I look at the configure logs when I build with the Intel
compiler. The test for -c -o fails, but I never see the compiler
script used. Maybe that is because the next test about hard links
succeeds on cygwin?

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

For me, I don't care about MS project files. It's the slowness of
cygwin that gets frustrating for me. No time or desire (at least
currently) to learn CMake and re-implement all the tests I do at
configure time.

Chris

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