On Wed, Aug 11, 2010 at 10:12 AM, Peter Rosin <p...@lysator.liu.se> 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 >