Closed rcst closed 2 years ago
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.
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.
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 ....)
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.
Sorry, I confused you by intermingling those three paragraphs. There are three distincts things going on:
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.
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.
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!
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...)
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 :)
Hello there!
I'm working on a R package that uses boost-process to pipe/ spawn/ stop processes. It's nice since this works across different platforms. It's header-only, so would you consider including it in BH?