AMDG On 08/11/2018 11:54 AM, Robert Ramey via Boost wrote:
I'm now taking steps to get safe numerics integrated into the boost distribution. It's reminded me of a running complaint I have about using boost.
a) When I use anything boost, I'm required to do two things:
i) run b2 headers to create a forwarding header in the boost directory ii) include via command line or INCLUDE variable to boost root.
b) If I want to use safe_numerics before it is included in the boost distribution, I have to place safe_numerics into it's expected destination in the boost hierarchy and run b2 headers AGAIN to make things match up. This is even more problematic in that b2 headers is not invoked "automagically" in such a way that people don't know it's there.
There's nothing stopping you from using safe_numerics outside the boost hierarchy with a separate -I option.
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. If you're *not* testing with `b2` then there's nothing that requires a new library to be inside the boost hierarchy at all.
Now I'm getting ready to add it to the boost distribution, I'll change this to do it the "boost way". Not so much because I think it's better but in this case, consistency is better than variety. But I'm still unsatisfied with the situation. It's part of the reason that boost is avoided when possible by many people.
Isn't there a better way? I think there might be.
Rather than sprinkling a bunch of forwarding headers around my file system - which are "sticky" and need to be updated from time to time,
Normally, the "forwarding headers" are symbolic links which never need to be updated (and will break loudly when they do).
how about depending on the "INCLUDE" environmental variables available in gcc and msvc and clang. Using "some method", I would be able generate this variable via some sort of batch script - not too tough. And work as I do now. But
a) the script would be re-run when ever I changed projects so that it "stuck" in my file system.
How is this any easier than re-running `b2 headers`?
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"
d) If my project is "larger" and includes a bunch of stuff from other libraries, I could add these in as well. This would give my the concept of "library federation" where my app is linked to some list defined as part of the project. I'm sure this concept also sort of exists.
e) my pet request would be that I could say:
tool application.cpp ... >include environment output
to generate the env output for all the target apps. Of course one could you * wild cards as well. This would let me create one set on includes for building/running my test suite and a different one for examples and a different one for my "real" application.
I'll stop there so as to leave opportunity for discussion.
I admit that the current system isn't perfect, but your proposal seems even more complex and harder to use. In Christ, Steven Watanabe