After some surgery, math/R is in more manageable shape. But, the surgery broke two slave ports, math/libR and math/libRmath. They have each been marked broken since June or July and I posted to ports@ about deleting them, but didn't get a response.
math/libRmath I'm not sure how widely used math/libRmath is today, but it's still described in R's main installation document (https://cran.r-project.org/doc/manuals/r-release/R-admin.html#The-standalone-Rmath-library). It *should* be straightforward to just incorporate math/libRmath's four files into math/R and then delete math/libRmath. The directory for libRmath is under WRKSRC, but it's not included in the main Makefile, so I'd have to either patch the main Makefile or do something with post-build and post-install. Is this palatable? --- post-build: ${SETENV} ${MAKE_ENV} ${MAKE_CMD} -C ${WRKSRC}/src/nmath/standalone post-install .for f in libRmath.a libRmath.so libRmath.so.${RMATH_SOVERSION} ${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/${f} ${STAGEDIR}/lib/ .endfor ${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/Rmath.h ${STAGEDIR}/include/ --- math/libR Right now, unlike upstream, math/R's shared library option is turned on by default. This was done only in late June because a dependency, math/rkward-kde4, required it. Upstream turns it off, for the reasons described in [1]. I'm inclined to remove the libR option from math/R's OPTIONS_DEFAULT and resurrect math/libR (or maybe math/R-libR by using PKGNAMESUFFIX) as a very simple slave port that just installs math/R with that option on. math/rkward-kde4 could then depend on math/libR. One issue is that, I believe, R's installed packages (packages installed from within R) and many of R's dependencies would have to be rebuilt after turning off the libR option. Opinions? Joseph [1] "--enable-R-shlib causes the make process to build R as a dynamic (shared) library, typically called libR.so, and link the main R executable R.bin against that library. This can only be done if all the code (including system libraries) can be compiled into a dynamic library, and there may be a performance [47] penalty. So you probably only want this if you will be using an application which embeds R. Note that C code in packages installed on an R system linked with --enable-R-shlib is linked against the dynamic library and so such packages cannot be used from an R system built in the default way. Also, because packages are linked against R they are on some OSes also linked against the dynamic libraries R itself is linked against, and this can lead to symbol conflicts." [47] We have measured 15-20% on i686 Linux and around 10% on x86_64 Linux.
signature.asc
Description: PGP signature
