On 11/3/11 7:05 AM, David Holland wrote:
On Wed, Nov 02, 2011 at 02:39:32PM -0400, Julio Merino wrote: > 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? My opinion is that given what Boost is, what it does, and the problems to be expected for it, we're better off wiring down its configuration
> as much as possible.What are these "problems to be expected"? Sincerely, it sounds like FUD to me... and there is already plenty of that surrounding Boost. (Yes, yes, some well funded :-P )
Anyway, leaving that aside... I'm all for wiring down the configuration as you say. What I'm afraid of is that we are intentionally diverging from what others do with Boost, so we are probably trying to use the least tested side of their configuration and thus exposing us to more problems than necessary...
That said, I took a look at the documentation of Boost.Config and, at least, they don't say anymore that the autoconf script is not supported. They actually seem to imply that it's a good thing to use on Unix systems... so my previous point may be moot!
No matter what, we need to find a solution to the problem at hand, and we don't have one yet.
It's hard enough trying to figure out wtf is going on in the C++ when something fails; wading through to figure out what its configuration system did to you as well will only make it that much worse.
That's not any different than wading through the autoconf stuff they have, which is also very "non-standard" and messy (last I looked).