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

[Anthony Mallet <anthony.mallet%laas.fr@localhost>]

On Wednesday, at 12:15, Julio Merino wrote:
| 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.

Unfortunately it's not a pkgsrc package, and won't probably ever be. That's
very specific research software that hasn't much interest outside the lab(s)
developing it.

Also, NetBSD is not strictly required. It's just that I try to ensure that the
software builds on something else than linux to improve the quality (and I
personnaly prefer working on netbsd, too :).

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.


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


| 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.

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

Well, if the software builds fine without c++0x then yes, I see no reason to
enable it. Until you find a software that actually requires a c++0x feature and
cannot build without. Then you'll know that you have to recompile (all of) your
boost software because you have to make update in devel/boost-* with the new
option.