Re: [boost] Library Federation

Subject: Re: [boost] Library Federation
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-08-11 20:12:53

On 08/11/18 20:54, 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.
> 
> 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.

Just for the record, gcc has CPATH and not INCLUDE. clang, probably, 
too, though I didn't check. Syntax is probably different from MSVC's 
INCLUDE, too.

Also, I might be mistaken, but I thought there was a rather short limit 
on the env. variable length on Windows, which may come into play with 
variables like PATH or INCLUDE.

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

I'm not quite sure what exactly you are proposing.

 From my experience, when I was developing Boost.Log, I simply symlinked 
its tree into my Boost tree and had almost no problems with that setup. 
I didn't even have to run `b2 headers` whenever I added a new header to 
the library because `boost/log` was already a symlink to my 
`include/boost/log` directory. So in my case, this setup was mostly 
painless.

I'm sure I wouldn't want to construct a setup based on environment 
variables because, as I usually do, I wouldn't want to modify my default 
environment this way. This would affect my work with other projects. 
Which would force me to create a special environment for working with 
Boost, which would just add more hassle.