Boost logo

Boost :

Subject: Re: [boost] Library Federation
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2018-08-12 04:11:56


On 08/11/2018 03:08 PM, Robert Ramey via Boost wrote:
> On 8/11/18 12:50 PM, Steven Watanabe via Boost wrote:
>> There's nothing stopping you from using safe_numerics
>> outside the boost hierarchy with a separate -I option.
> Hmmm - wouldn't the require I mess with b2 switches? ouch.
  Since safe_numerics is header-only, the only thing
that you need to mess with is the include path.

>>> 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.
> Hmmm that's news to me.  It seems that I've always had to do this but
> maybe that changed when I wasn't looking.

  It was always supposed to work that way, and I think I got
most of the wrinkles ironed out a long time ago. Currently,
running `b2 headers` is necessary iff. you are working on
a filesystem that supports neither symlinks nor junctions.
This happens solely because the #include scanner in b2
misses some dependencies (specifically #include through
a macro). I have always assumed that this situation where
we have to fall back on making a full copy of all the headers
is rare.

>> How is this any easier than re-running `b2 headers`?
> It's not really easier - I just prefer the result.  The redirecting is
> internal and "permanently" embedded into the 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.
>> Okay, I'm confused here.  If this is all handled
>> automagically, then there's nothing absolutely nothing
>> protecting you from "accidentally including surprising
>> stuff"
> OK - I envisioned that only those boost libraries used by the target
> would be in the include list.  One would then be be able to add any
> other "foreign" directories required by other libraries.
>> I admit that the current system isn't perfect,
>> but your proposal seems even more complex and
>> harder to use.
> LOL - of course we disagree.

  Ha. I suppose I am a bit biased, as I implemented
most of the current system. Anyway, I'm not willing
to spend my own time on implementing this, but feel
free to take a stab at it yourself. It can, at least,
be made to work for non-b2 consumers without breaking
the current setup.

In Christ,
Steven Watanabe

Boost list run by bdawes at, gregod at, cpdaniel at, john at