AMDG On 08/11/2018 03:08 PM, Robert Ramey via Boost wrote:
On 8/11/18 12:50 PM, Steven Watanabe via Boost wrote:
There's nothing stopping you from using safe_numerics outside the boost hierarchy with a separate -I option.
Hmmm - wouldn't the require I mess with b2 switches? ouch.
Since safe_numerics is header-only, the only thing that you need to mess with is the include path.
To me, this just makes it harder to use / test any new library with boost without dragging in access to a bunch of stuff I may not want. It inhibits those without beam foo from running the tests etc. This is why I did things the way I did.
If you're testing with `b2`, then you don't need to run `b2 headers` separately.
Hmmm that's news to me. It seems that I've always had to do this but maybe that changed when I wasn't looking.
It was always supposed to work that way, and I think I got most of the wrinkles ironed out a long time ago. Currently, running `b2 headers` is necessary iff. you are working on a filesystem that supports neither symlinks nor junctions. This happens solely because the #include scanner in b2 misses some dependencies (specifically #include through a macro). I have always assumed that this situation where we have to fall back on making a full copy of all the headers is rare.
How is this any easier than re-running `b2 headers`?
It's not really easier - I just prefer the result. The redirecting is internal and "permanently" embedded into the file system.
b) It could be smarter - include only the boost include directories I'm actually using - thus avoiding accidently including surprising stuff.
c) We have tools which figure out boost dependencies automatically so I don't think it would be a big stretch to do this automagically.
Okay, I'm confused here. If this is all handled automagically, then there's nothing absolutely nothing protecting you from "accidentally including surprising stuff"
OK - I envisioned that only those boost libraries used by the target would be in the include list. One would then be be able to add any other "foreign" directories required by other libraries.
I admit that the current system isn't perfect, but your proposal seems even more complex and harder to use.
LOL - of course we disagree.
Ha. I suppose I am a bit biased, as I implemented most of the current system. Anyway, I'm not willing to spend my own time on implementing this, but feel free to take a stab at it yourself. It can, at least, be made to work for non-b2 consumers without breaking the current setup. In Christ, Steven Watanabe