[boost] Library Federation

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 
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.

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.

Robert Ramey