[Bug 211393] math/R: update patches and options

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211393

            Bug ID: 211393
           Summary: math/R: update patches and options
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Keywords: patch
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: freebsd-ports-bugs at FreeBSD.org
          Reporter: jrm at ftfl.ca
 Attachment #173018 maintainer-approval+
             Flags:

Created attachment 173018
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=173018&action=edit
svn diff to improve math/R

Proposed changes:

- Always build the shared library, libR.  I can't think of a good reason not to
always turn this on.  Unless I'm missing a use-case, this eliminates the need
from math/libR.

- Memory profiling can cause problems with external BLAS, so only turn on
memory profiling with R's internal BLAS.

- Use R's internal BLAS by default.  The authors recommend the internal BLAS
for most use cases, because it is more widely tested.  I've also encountered
occasional segmentation faults with OpenBLAS.  Any potential speed gains with
machine-customized OpenBLAS, if any at all, shouldn't trump stability.

- Add ONLY_FOR_ARCHS=i386 amd64.  Building on ARMv6 fails (even with the
updated patches that were relevant for ARMv6) and, I'm told, there are other
run-time problems related to calling fortran libraries from C on ARMv6.  I
don't have any powerpc hardware (yet) to test on.  Anyone interested in testing
there?

- Add a workaround for broken autoconf JPEG detection.

- Don't force GCC as the C compiler.  This has implications for dependent ports
and wen@ should provide feedback before this is committed.  [1]

- Present the options organized by major dependencies.  For example, group LTO
and OPENMP together because they, for now, both require GCC.  Newer versions of
clang support both, so we can look into turning these options on by default
soon.

- LIBMISSING is no longer required because support for ARMv6 and powerpc have
been removed.  My guess is that it wouldn't be required (without LONGDOUBLE) in
any case with the removed workarounds for quadmath.

- Remove the THREADS options.  The configure flags --enable-threads=posix
versus --disable-threads doesn't seem to have any effect on the build.

- Remove patches that are no longer required, because they have been fixed
upstream.  The workaround in patch-src_extra_tre_tre-internal.h has been
included upstream, but an #include <stdint.h> is missing.  This is the only
line in the updated patch.

[1]

I see cran.mk has

.if ${cran_ARGS:Mcompiles}
.include "${PORTSDIR}/math/R/compiler.mk"
.endif

A quick search shows

./R-cran-lme4
./R-cran-memisc
./R-cran-MCMCpack
./R-cran-influenceR
./R-cran-mcmc
./R-cran-RcppArmadillo
./R-cran-Rcpp
./R-cran-tibble

would be affected.

Wen, can you suggest how you would like to handle this?  It would be nice to
not force GCC if it's a reasonable change for these dependent ports.

portlint: 
WARN: Makefile: unless this is a master port, PORTNAME has to be set by "=",
not by "?=".
WARN: Makefile: do not call install-info directly.  Use the INFO macro instead.
(spurious)

testport: OK (poudriere: 9.3-RELEASE-p44, i386,  default options)
testport: OK (poudriere: 9.3-RELEASE-p44, amd64, default options)
testport: OK (poudriere: 10.3-RELEASE-p5, i386,  default options)
testport: OK (poudriere: 10.3-RELEASE-p5, amd64, default options)

-- 
You are receiving this mail because:
You are the assignee for the bug.