Re: [boost] Library Federation

Subject: Re: [boost] Library Federation
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-08-11 19:50:07

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