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.