[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: boost, BOOST_HAS_VARIADIC_TMPL and std=c++0x
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)
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
Main Index |
Thread Index |