Eric,
Well, rather, compiled and misbehaved. Not particularly in an unpredictable fashion.
Still, if this version of boost ended up in an ubuntu release, or some such, then a lot of people might end up with miscompiled code. I was looking forward to using utree, and now I am going to have to add an explicit version test, to make sure I don't pick up this broken version.
Unfortunately, people tend to just try compiling code they get with whatever is on their system first, and don't check headers.
If the particular headers are just never supposed to be included, they could just be 'poisoned' with a #error, or as you say deleted. I realise this might hold release up, but would avoid known-broken code being released.
I would be ok with poisoning the broken header with #error. That's in addition to removing any mention of the broken feature from the docs and release notes. But please do it soon. I think the beta is to be rolled tomorrow.
poisoning the utree headers touches exactly the same set of files as pulling them. The overall design makes utree completely nonintrusive to other parts of Spirit, the headers are not included anywhere. The same is true for the tests: the Jamfiles have to be touched in any case. May I ask for permission to remove the files instead of poisoning them? The risk is the same, but the result much more desirable... Regards Hartmut --------------- http://boost-spirit.com