Subject: [boost] Library Federation
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-08-11 17:54:55
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
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.
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.
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,
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.
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk