Include boost process? about bh

[eddelbuettel]

Sorry, I confused you by intermingling those three paragraphs. There are three distincts things going on:

1. BH is currently at 1.75.0. You could augment it within your package with a local copy of the files from process (and what they need). Your package could build and be CRAN-sufficient.

2. In parallel, we could extend BH to also include process. You could test with that variant. We could do that via the ghrr drat repo.

Points 1. and 2. are not interdependent.

[eddelbuettel]

Or keep the request open and add Boost process at the next update of BH?

(Header-only generally means "no linking", i.e. no -lsomelibnane possibly requiring -Lsome/dir, it can mean rely on other directories / Boost libraries which may have linking requirements which would make the aggregate non-header-only; sometimes dependencies from other Boost library (which they themselves may need linking) can still be header-only. It's all a little head spinning at times...)

[eddelbuettel]

Header-only would qualify, so that is good. [Checks] Seems to look good indeed. I guess I am in favour.

How 'soon' do you need it, and/or could you work for a bit and test with local copies? I try to avoid updating more that once a year now. I could create a local version now (not "that" much work) and only upload to a drat repo for access via normal package functions.

[rcst]

Thanks for considering. Yes, sure, I'd be glad to support. It is not "urgent" as there are quite a number of other things on my package that need attention for my goal to publish it on CRAN. I'd therefore like to improve portability of my package.

I think I just realized that boost/process.hpp depends on boost/system.hpp, more specifically boost/system/error_code.hpp. Luckily, boost-system is header-only too (>=1.69). So I'm actually asking to add both process and system. I'm sorry, this foot-in-the-door wasn't originally intended.

drat sounds splendid, didn't know about it before.

[eddelbuettel]

We actually use bcp with a repo name, so it would just out of system whatever process needs. That's why we already have more directories than "formally listed" components.

And yes, using drat is awesome. Because R's package management system is awesome, and easy enough to extend with local repos, especially hosted at GitHub (say) via GitHub Pages. I use a dedicated drat for Rcpp pre-releases and one more catch-all one. Works great.

We could even try to document adding process: create a new bh package, release to the ghrr drat, but also add ("for now") an include/ in your package to allow seamless interop. If we stick to the same Boost version in bh (currently 1.75.0) we should be good. (This last paragraph implies more work and I know nobody has time but ....)

[rcst]

I'm sorry I needed some time to absorb your last message. I'm not absolutely clear however whether I should also release my package to drat to "allow for seamless interop"? How would my package access then the ghrr drat the interim release of bh that contains the required headers? Or do you mean I should simply include/ the missing headers within the package?

Sorry for my lack of proficiency in this regard.

[rcst]

Thanks again for pointing me to drat, it's really nice. I set it up for my package.

It took me a while to think this through, but as far as I understand, the "header-only"-property of a given specific Boost library does not necessarily propagate to all the dependencies of that library. To me this seems a bit weird and misleading. I checked it using bcp and the process library clearly depends on things like chrono and filesystem.

I found an alternative in my case and now I'm not depending on any boost library. (Hopefully it will stay like this). From my side, we can close this request.

Anyway thanks for considering!

[eddelbuettel]

It is the annual time of a BH update to get to the just-release Boost 1.78.0 and I will include Boost process in this round. Understood you ended up not needing it but it is still a useful library :)