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