Fixed incorrect tags when using Mingw GCC 4.1.8.

Now properly detected as mgw48 instead of gcc48.
This closes #53.

Signed-off-by: Benoit Sigoure <tsunanet@gmail.com>
Fix POINTERCONTAINER -> POINTER_CONTAINER

The name used in the comments is not the name by which the macro can be called.

Signed-off-by: Benoit Sigoure <tsunanet@gmail.com>
Fix a small silly copy-paste error.
Perform sed and -mt code checks in C++ mode

The default language is C, but since Boost is inherently a C++ library,
it makes sense to invoke the C++ compiler for all Boost-related Autoconf
tests, even if no C++ code is actually being compiled.

This change wraps the call to `_BOOST_SED_CPP` when detecting Boost's
version, as well as the code for detecting the environment's
multithreading status.

This has an added side effect, which is that when not using Libtool,
there's no dependency on C at all -- the CC, CFLAGS, and CPP macros
don't affect the configure script. Technically, Boost.m4 depends on
Libtool, but in my experience, the only thing it uses is the $libext
variable, and then only when searching for a static library to link
with. I can circumvent the full Libtool dependency by simply setting
$libext directly (usually to `a`, but to `lib` on Windows compilers).
This allows for faster configurations since we don't have to detect and
test the capabilities of a C compiler that will never actually be used.

Signed-off-by: Benoit Sigoure <tsunanet@gmail.com>
Add function for detecting boost MPI, which uses BOOST_FIND_LIB.

If the MPICXX variable is set (by ax_mpi.m4, acx_mpi.m4 or similar),
then set the CXX and CXXCPP variables prior to the check and restore
them afterwards.  Otherwise the standard CXX variable is used.

Signed-off-by: Benoit Sigoure <tsunanet@gmail.com>
ignores: update
boost.m4: provide a means to look for different library base names

A recent change seems to be dictated by the fact that on MingW, the
thread library is actually name thread_win32.  The patch is somewhat
uglified because the library name is also used to compute the name of
the output variables.  This shows that it is desirable to separate the
component name (e.g., thread), from the real shared-object base name
(e.g., thread or thread_win32).

* build-aux/boost.m4 (_BOOST_FIND_LIBS): New.
Includes the part of BOOST_FIND_LIB that used to look for the library,
inside the AC_CACHE_CHECK.
(BOOST_FIND_LIBS): New.
Contains what used to be around the library look up.
(BOOST_FIND_LIB): Backward compatibility layer.
boost.m4: use BOOST_FIND_LIBS to deal with thread_win32

* build-aux/boost.m4: Here.
This reduces the generated code bloat.
boost.m4: promote BOOST_THREAD over BOOST_THREADS

* build-aux/boost.m4 (BOOST_THREADS): Rename as...
(BOOST_THREAD): this.
(BOOST_THREADS): New backward compatibility definition.
boost.m4: beware that Boost.Python may have a libboost_python3 library

This is the case on ArchLinux for instance.

* build-aux/boost.m4 (BOOST_PYTHON): Check the possible python3
library basename.
* README, tests/testsuite.at: Adjust.
boost.m4: fix the witness header for Boost.LogSetup

* build-aux/boost.m4: I don't have boost/log/utility/init/from_settings.hpp,
but boost/log/utility/setup/from_settings.hpp.
I have no idea when this was changed, and no desire to know :)
boost.m4: style changes

* build-aux/boost.m4: Don't call AC_SUBST gratuitously.
Indent.
Comment changes.
boost.m4: introduce Boost.Flyweight check

* build-aux/boost.m4 (_BOOST_PTHREAD_FLAG): Documentation changes.
(BOOST_FLYWEIGHT): New.
boost.m4: do not issue useless -rpath /usr/local/lib

Serial 22.

Symptoms: on ArchLinux, some library linked with Boost thanks to
boost.m4 end up with the following errors:

vaucanson-git E: Insecure RPATH '/usr/local/lib' in file
('usr/lib/python3.4/site-packages/vcsn_cxx.so')
vaucanson-git E: Insecure RPATH '/usr/local/lib' in file
('usr/lib/vcsn/libvcsn.so.0.0.0')

The weird thing is that there is no reason for this dependency on
/usr/local/lib.  Careful reading of boost.m4 shows this is not
intended.  Indeed the empty library location ('') is tested first, but
the code that follows is not ready to handle an empty path, which
results in various errors that are misunderstood as meaning that the
libraries are not there.  So the next successful location tried (which
turns out to be /usr/local/lib) will be "accepted", and uselessly
propagated to the linker both as -L and -rpath.

* build-aux/boost.m4 (_BOOST_FIND_LIBS): Try first without any -L,
-rpath etc.

Signed-off-by: Benoit Sigoure <tsunanet@gmail.com>
Add a BOOST_NUMERIC_UBLAS test.

Signed-off-by: Benoit Sigoure <tsunanet@gmail.com>
Merge remote-tracking branch 'upstream/master'