Re: boost, BOOST_HAS_VARIADIC_TMPL and std=c++0x

[Julio Merino <jmmv%NetBSD.org@localhost>]

On 11/2/11 11:13 AM, Anthony Mallet wrote:
> Hi,
>
> Thanks for you answer.
>
> On Wednesday, at 10:22, Julio Merino wrote:
> | 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.
>
> Yeah, a pkg-config or similar would be cleaner. The sofware I try to compile is
> not really mine and it already uses cmake for the build, so changing to
> boost.build is not really an option.

I see.  Is the software being built as a pkgsrc package?  If so, we 
could do some tricks in the boost buildlink3.mk file to pass around the 
right compilation flags.

> | 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.)
>
> I definitely agree with you when you say that mixing different compilers is
> probably wrong. Yet, the user.hpp file found on the linux box that I have
> access to are not setup like this (i.e. they don't define BOOST_NO_CONFIG and
> rely on runtime detection). So I don't know how it works for linux (and I will
> never claim that Linux is a reference :), but it _seems_ to work (maybe that's
> just an illusion :)

Well, the problem is that Boost.Config relies on "static assumptions" 
that, over time, have proven to be not really that portable to "obscure" 
Unix platforms (NetBSD being one of them) and hardware platforms (again, 
NetBSD being a good example due to the wide hardware support).  In 
particular, I recall several issues in NetBSD and, at the time, were 
"easily" fixed by switching to the autoconf alternative.

Maybe it's time to revisit the decision of using autoconf.  Boost.Config 
clearly works in other platforms and should be doing the right thing 
already... maybe what we ought to do is cope with any problems that 
arise in Boost.Config and fix them in the library instead of working 
them around by using the autoconf approach.    Maybe the answer to this 
is just to provide build slaves for the Boost testing system that run on 
multiple NetBSD variants; this way, they'd have data on their dashboards 
(1).

That said, doing the change is tricky.

> So I don't know. Maybe the boost-* packages could just define a c++0x option,
> so that you install boost with enabled/disabled support for c++0x ?

I don't think this is a good idea.  Why would you ever want to enable 
this option if the package built without it would work in all cases, and 
be "more compatible"?

1: http://www.boost.org/development/tests/release/developer/summary.html