Compiling of dependancies on Mac OS

[TomKellyGenetics]

As mentioned in the README there is an issue with compiling of the dependancy "RcppArmadillo" on Mac OS (for R versions 3.0 and above). This is due to a mismatch in gfortran versions for the package and used to compile R itself. The solution is well described here: https://thecoatlessprofessor.com/programming/rcpp-rcpparmadillo-and-os-x-mavericks--lgfortran-and--lquadmath-error/

While this ultimately a dependency issue, it would help those encountering this issue to direct them to this. Perhaps in the README?

While I've managed to install RcppArmadillo on my system, I worry that it is such an inconvenience to R users on Mac OS that I am reconsidering to include functions dependent on it in my package.

[eddelbuettel]

That is indeed an issue but I think that the 'recommended' approach seems to change with just each about every R or macOS release :-/ That makes a canonical recommendation "hard".

I am not sure what you are trying to say in your last paragraph. This is not a CRAN package pretty much for that reason. "It is hard" with the external library.

[TomKellyGenetics]

Thanks for giving this some consideration, it does seem to be an issue that needs to be addressed case-by-case unfortunately. I've got it working on my system now so it seems to be fully functional and would be great if I needed to run the full suite of ML algorithms. However, I'm not sure it's worth including it in an R package (yet) if it's going to send unsuspecting users (even if only on Mac) into dependency issues when all I'm looking for is a faster PCA.

Since this seems to be due to inconsistent Fortran versions used to compile R and the package, hopefully this may be resolved in time with future releases of R. I presume they intend to update to a newer version at some point.

[eddelbuettel]

It is of course really both an (Rcpp)Armadillo and macOS issue aggravated by the fact that (Rcpp)MLPACK uses these.

[coatless]

@TomKellyGenetics: Real quick, did you compile MLPACK locally or was this through one of the package mangers?

Previously, we relied more heavily on brew, which was very problematic. (The brew formula is now deprecated).

Given what I now know about R's compile stages and the upgraded R toolchain for macOS, we can likely support macOS and move this onto CRAN.

@eddelbuettel we'll need to follow the x13prebuilt route that seasonal took.

[coatless]

Notes to myself for testing on a VM later this week:

mkdir -p ~/inst && cd ~/inst

# Install Armadillo
curl -O https://svwh.dl.sourceforge.net/project/arma/armadillo-8.500.1.tar.xz
tar zxvf armadillo-8.500.1.tar.xz && cd armadillo-8.500.1
./configure
make && make install

# Install boost
cd ../
curl -O https://dl.bintray.com/boostorg/release/1.67.0/source/boost_1_67_0.tar.gz
tar zxvf boost_1_67_0.tar.gz && cd boost_1_67_0
./bootstrap.sh
./b2 install

# Install MLPack
cd ../
git clone https://github.com/mlpack/mlpack
cd mlpack && mkdir build && cd build
cmake  -D BUILD_PYTHON_BINDINGS=OFF ../
make && make install

[eddelbuettel]

@eddelbuettel we'll need to follow the x13prebuilt route that seasonal took.

No, as x13prebuilt is a binary. Maybe you were thinking of Rblpapi using a free-to-use-but-no-source library we pull in from here.

I also just experimented (at work) with building a (set of) static libraries compiled with -fpic -- those can be pulled into a shared library an R package builds for itself. So we might pull off a library package.