On 10/31/11 8:15 AM, Anthony Mallet wrote: > [...]
My problem: this forces the use of -std=c++0x for all software willing to use
boost.
While if BOOST_NO_CONFIG if not defined, boost does some automatic feature
detection and one can use either "g++" or "g++ -std=c++0x", depending on the
actual requirements.
So my questions are:
- did I miss something? (I want to compile my software without -std=c++0x).
- Is the boost setup really meant to be like that (couldn't it avoid defining
BOOST_NO_CONFIG)?
Yeah, the fact that it defines BOOST_NO_CONFIG is on purpose, because the packages use the included configure script to generate the user.hpp file. As a result, BOOST_NO_CONFIG gets defined to indicate that only the results of the configure script are to be used.
(E.g. my NetBSD machine has BOOST_HAS_VARIADIC_TMPL in it and my OS X machine has BOOST_NO_VARIADIC_TEMPLATES.)
I think this is a general configuration issue. It seems to me that the Boost configure script is passing -std=c++0x as an attempt to be "smart" and detect variadic tmplates. However, by doing so, this ends up forcing the end user to use the same compiler as you have discovered. I don't have a real solution for this other than explicitly disabling variadic templates in the package... but that is very ugly, I guess.
Other libraries (not Boost) solve this problem by providing a pkg-config file that stores the necessary flags that users of the library must use. Maybe Boost.Build already provides this functionality and you should just be using it; I don't know.
The other alternative is to NOT run autoconf in our packages and rely on Boost.Config. This has caused problems in the past, and I'm afraid it will open the door to many other problems though: for example, consider boost-libs. If you are linking against installed binary libraries that were compiled with -std=c++0x and you don't use this flag in your build... there may be problems. (The same applies to any of the other automatically detected features; -std=c++0x is just the example at hand.)