Maybe send a PR to BH instead ...

[eddelbuettel]

... of using a poetically named path?

BH is not exactly a closed system as even a casual perusal of its NEWS.Rd file will tell you. [ Apologies for the unrendered Rd file; the version of NEWS.Rd on CRAN missed the last update. ]

[maverickg]

Well, it is not just as simple as sending a PR to BH, which we had done before and for which we appreciated your help. But here for some reason I can recall now, we have 9c0e10b.

[eddelbuettel]

gcc test for up to 4.6. Hm. A Windows issue?

[bgoodri]

Sorry @eddelbuettel ; I didn't make a PR yet because I wasn't sure of what the right fix was and didn't want to introduce a hack that worked for rstan but not some other package.
The original boost bug I reported https://svn.boost.org/trac/boost/ticket/11517 (which is not limited to Windows but is limited to g++ <= 4.6)
Which they fixed in 1.59.0 according to the too limited one-liner I gave. But for some reason that I haven't figured out yet, their fix didn't actually fix the problem when you actually try to build something that includes unused.hpp .
So, rstan/inst/include/boost_not_in_BH still has my hacked unused.hpp that allows rstan to build, but I am still not sure it is the right thing to do.

[eddelbuettel]

Well maybe we should carry that forward as BH is used by 25+ packages now ...

[bgoodri]

If you think it would be helpful to take that unused.hpp file for BH, go ahead. Also, the actor.hpp file in boost_not_in_BH I am not sure about either. We changed that in Stan to work around a compiler error with the Intel C++ compiler, and it didn't adversely affect our unit tests, but I have no idea how it would affect anyone else's code.

[eddelbuettel]

It's a trade-off. I want useful enhancements and corrections, but I don't want to be caretaker of a bunch of isolated patches.

[eddelbuettel]

If you still care, BH 1.60.0-1 is now on CRAN with, inter alia, Boost phoenix.