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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
