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

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

+ brook

On 11/2/11 1:37 PM, Anthony Mallet wrote:
> All of this was hidden as long as we had gcc-4.1. Now that we have 4.5, I
> thought that my specific problem was more general and could potentially hit
> other people, so that's why I am raising the issue here.

Interesting.  Haven't seen it here though yet, but it can definitely 
affect other people.

> | 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.
>
> I see. I'm not familiar at all with Boost Config, but I see there are
> alternatives to BOOST_NO_CONFIG. Since NetBSD is using standard gcc, maybe just
> defining BOOST_NO_STDLIB_CONFIG and BOOST_NO_PLATFORM_CONFIG (so that
> BOOST_NO_COMPILER_CONFIG is not defined) could do the trick?

The breakage doesn't generally come from the compiler; that's usually 
fine because, as you say, we just use plain gcc (and have been doing so 
for a long time).  Problems usually pop out due to differences in our 
header files (different dependencies, missing functionality, misdetected 
features...).

> | 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).
>
> It makes sense. I guess it will be quite hard to determine if Boost.Config is
> OK for all netbsd variants, though.

To be frank, Boost is a constant source of problems on arbitrary 
platforms.  Sure, by switching to Boost.Config we may uncover other/more 
problems, but I don't think it will make things significantly worse.

I'd like someone else's opinion on this though before even trying to 
make the packages not use the autoconf alternative.  Maybe Brook can 
comment?