[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Optimizing repeated calls to AC_TRY_LINK
From: |
Ralf Wildenhues |
Subject: |
Re: Optimizing repeated calls to AC_TRY_LINK |
Date: |
Mon, 7 Jan 2008 21:59:51 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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
- Re: Optimizing repeated calls to AC_TRY_LINK,
Ralf Wildenhues <=