[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Optimizing repeated calls to AC_TRY_LINK
From: |
Benoit Sigoure |
Subject: |
Optimizing repeated calls to AC_TRY_LINK |
Date: |
Tue, 20 Nov 2007 02:05:50 +0100 |
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.
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?)
B. Seldom use-case with possibly dangerous effects: learn to live
with it.
C. You will burn in Hell for having profaned Autoconf's internals.
D. The answer D.
Comments welcome.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
PGP.sig
Description: This is a digitally signed message part
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Optimizing repeated calls to AC_TRY_LINK,
Benoit Sigoure <=