On Jan 7, 2008, at 9:59 PM, Ralf Wildenhues wrote:
Hello Benoit, and sorry for the long delay,
No problem ;o
* 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.
I can't. The goal is to find the most precise library name given the
user request. So when I try to find, say, libboost_foo-gcc41-mt-
d-1_34_1, I want to search all the directories. If this one can't be
found, I'll try a less restrictive version of the library name (say,
libboost_foo-gcc41-mt-d) and so on (until the canonic name
libboost_foo).
While we're here, this has a very bad consequence. I tend to link
with the most precise -lflag (e.g. libboost_foo-gcc41-mt-d) which
totally prevents the binaries to work after system updates, even
though non-major updates remain ABI-compatible. That seriously
sucks. Ideally, once I find a precise -lflag that works, I'd like to
find the simplest -lflag that corresponds to the same shared object.
If you have an idea as to how to implement this portably, let me know.
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 ;-).
Excellent idea. I'll implement this.
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?
Yes. I don't know when, but be sure I'll give it a try as soon as I
can.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
