Closed Enchufa2 closed 4 years ago
I suspect that some headers lead to a linking requirement. That is the same for some other Boost libraries. So there may be both supported and unsupported use case.
Looks like filesystem has been part of BH for some time, but it also looks like may need compilation. From its documentation:
Using the library
Boost.Filesystem is implemented as a separately compiled library, so you must install binaries in a location that can be found by your linker. If you followed the Boost Getting Started instructions, that's already been done for you.
So maybe we should remove it...
I found this, and the following define
seems to solve the issue:
Rcpp::sourceCpp(code='
#include <Rcpp.h>
// Rcpp::depends("BH")
#define BOOST_ERROR_CODE_HEADER_ONLY
#include <boost/filesystem.hpp>
// [[Rcpp::export]]
int hello() { return 0; }
')
If this is enough to make it work, maybe BH should set that define
by default.
Dang, that is excellent. I was actually just looking at Boost filesystem a few weeks ago for this commit in RcppCNPy and ended up going to R instead because of the linking issue. Need to look some into this.
We may need a new FAQ vignette with this in it.
Ok, I checked, If I actually want to invoke filesystem functions that seem system dependent ("does path exist?") I still get error, particularly boost::filesystem::detail::status(boost::filesystem::path const&, boost::system::error_code*)
being undefined. No free lunch...
That's a pity, but sounds reasonable though. It appears that only some path utilities (which are nothing but string manipulations) can be used without linking. I'd vote for removing it then.
Agreed and retitled. I think on the next update I will remove it.
This might be a dumb question, but why exactly is there talk about removing a component such as filesystem
? Personally I hope, this does not happen as I just included BH
provided boost::filesystem
into a project of mine.
Isn't it sufficient to add something like PKG_LIBS = -lboost_filesystem
to Makevars
for linking? To be honest, I was surprised how easy this was (maybe, I'm lucky that boost libs are available from one of my system library directories), but @eddelbuettel suggested this both on SO and is doing so in a package.
Isn't it sufficient to add something like PKG_LIBS = -lboost_filesystem
Sure. Only that libboost_filesystem
is not part of this package, so you are now mixing your local installation with the package. Nothing "wrong" with that but you can't distribute that code.
And of course if you have a full Boost locally you don't need the BH
package....
No I don't as it is header-only as well.
I'm sorry, I did not read Makevars of rcppbdt correctly: PKG_LIBS
is commented out.
## Needed for the 'non-streams' variant charToPOSIXctNS
#PKG_LIBS = -lboost_date_time
So to do this properly, I need to add a configure
script to look up boost include & lib dirs on the target machine and maybe add boost as SystemRequirements
, right?
Do you off the top of your head know of a package that does something like this?
Correct. (And I myself had forgotten I once had a tester function needing linking. The intent for all this Boost use was always portability -- no linking.)
Because it is a real problem. I have two projects I am involved in blocked from CRAN access because they require linking with boost:
So I in short I would recommend to you to avoid linking if CRAN is your goal.
Thanks a lot for sharing your insight. One last question: I can easily swap boost::filesystem
for C++17 std::filesystem
. Is that also a problem with CRAN?
Sadly, yes. Some packages currently use C++14 but as far as I know nothing beyond. Once the Rtools set gets updated (to, I think, g++ 8) you can assume it on Windows.
Ok, thanks for the help!
Preparing BH 1.72.0 now based on last week's Boost 1.72 release. I removed filesystem
from the list of explicitly added packages ... but some of its files are still coming in via bcp
and cross-library dependencies. Such is life ...
I tried to use
boost::filesystem
, which is listed as available in BH, but it seems that it requires linking toboost::system
:gives
undefined symbol: boost::system::generic_category()
.