Re: Optimizing repeated calls to AC_TRY_LINK

[Ralf Wildenhues]

Hello Benoit, and sorry for the long delay,

* Benoit Sigoure wrote on Tue, Nov 20, 2007 at 02:05:50AM CET:
> Hi list,
> I have a problem with my boost.m4 macro: it's too slow.  Boost is being 
> very unhelpful because it can be installed in many different places and 
> the libraries can have many different names.  So what I do is that I 
> create all the reasonably possible library names and then try to link 
> against each of them for each usual install path (/usr/local/lib, 
> /usr/lib, /opt/local/lib, C:/Boost/lib, etc.).  Even though I skip all 
> non existing paths and everything, I end up doing several calls to 
> AC_TRY_LINK before I correctly guess the right combination of flags to 
> use.  The macro is *much* more reliable than other existing macros but 
> embarrassingly slow.  Someone suggested something very simple: why not 
> compile conftest.o once and then try various combinations of flags to 
> link it?  After all, it's the compilation step that takes time (C++, 
> Boost, you know...).  Unfortunately, I think this is impossible to 
> achieve with current Autoconf, because all macros always endup cleaning 
> conftest.$ac_objext.  I had to work around this and fiddle with Autoconf  
> internals (Forgive me Lord For the wrongs I have done: http:// 
> repo.or.cz/w/boost.m4.git?a=commit;h=7e5098a) and I'd like to avoid  
> that.

First of all, I think you should reorder your tests in boost.m4.
Make the loop

 273     for boost_ldpath in "$boost_tmp_lib/lib" '' \
 274              /opt/local/lib /usr/local/lib /opt/lib /usr/lib \
 275              "$with_boost" C:/Boost/lib /lib /usr/lib64 /lib64

the outermost one, if only for locality of reference.  Then,
if $boost_ldpath is nonempty, try a globbing match in that directory,
and if that turns out empty, just skip all the other loops (a complete
directory read is not cheap, but may just be a lot cheaper than lots of
compiles):

  set x *boost_*
  test $[]# = 1 && continue

Report back if that breaks with a library naming scheme on some system
(so that I don't recommend it again ;-).

> What do you think?
>   A. Autoconf can be enhanced to do this sort of thing (what should be 
> the interface?  who's in charge of cleaning conftest.$ac_objext?)

Well, I suppose you could define an
  AC_LINK_OBJECT([ACTION-IF-TRUE], [ACTION-IF-FALSE])

that can be used inside the ACTION-IF-* arguments of AC_COMPILE_IFELSE.

  AC_COMPILE_IFELSE(PROGRAM, [ACTION-IF-TRUE], [ACTION-IF-FALSE])

compiles PROGRAM, and only cleans up after the respective action is
executed.

AC_LINK_OBJECT may even get away with using $ac_link if it temporarily
resets $ac_ext to $ac_objext, and empties $ac_fcflags_srcext for
Fortran.  Dunno about Erlang, that may be a problem here.
AC_LINK_OBJECT should not remove stuff generated by AC_COMPILE_IFELSE
in order to facilitate being used several times in a row.

Would you like to go for it?

Cheers,
Ralf