tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

+ 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
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?

Home | Main Index | Thread Index | Old Index