Consider retiring LAPACK capabilities check

[eddelbuettel]

Recent R versions (IIRC R 4.5.0 or later) have / should have a feature-complete LAPACK even when building with the internal Rlapack. If memory serves, it is even planned to move away from internal LAPACK. So the check we have in configure.ac namely

## external LAPACK has the required function
lapack=$(${R_HOME}/bin/R CMD config LAPACK_LIBS)
hasRlapack=$(echo ${lapack} | grep lRlapack)

## in what follows below we substitute both side of the define/undef
## while this may seem a little unusual we do it to fully reproduce the
## previous bash-based implementation

if test x"${hasRlapack}" = x""; then
    ## We are using a full Lapack and can use zgbsv -- so #undef remains
    AC_MSG_RESULT([system LAPACK found])
    arma_lapack="#undef ARMA_CRIPPLED_LAPACK"
else
    ## We are using R's subset of Lapack and CANNOT use zgbsv etc, so we mark it
    AC_MSG_RESULT([R-supplied partial LAPACK found])
    AC_MSG_WARN([Some complex-valued LAPACK functions may not be available])
    arma_lapack="#define ARMA_CRIPPLED_LAPACK 1"
fi

may be too harsh. I don't think I have a system to test this on: all mine use system lapack as do the cloud instances I have access to.

So in short maybe removing

AC_SUBST([ARMA_LAPACK],["${arma_lapack}"])

and its use in the generated header

#ifndef ARMA_CRIPPLED_LAPACK
// value on next line may be changed between #undef and #define by the configure script
@ARMA_LAPACK@
#endif

is appropriate now?

[eddelbuettel]

@barracuda156 Can you advise what it looks like on your (somewhat non-standard / more exotic) macPorts system?

[eddelbuettel]

@barracuda156 Just in case, and while I do not think you need, there is now a branch for this:

https://github.com/RcppCore/RcppArmadillo/tree/feature/simpler_lapack_setup

[barracuda156]

@eddelbuettel Thank you!

Can you advise what it looks like on your (somewhat non-standard / more exotic) macPorts system?

Could you specify, what to check (which header)?

P. S. I will look into rebuilding R with external LAPACK, provided Reference-LAPACK/lapack#1105 get resolved, which I gonna try now.

[eddelbuettel]

@barracuda156 In issue ticket #4001 over at mlpack you wrote in this comment that

On a side note, what is the advised usage of LAPACK now? mlpack build spits out a lot of option ARMA_CRIPPLED_LAPACK is not supported messages now. Looks like that comes from RcppArmadillo.

If you try the branch I pointed to (or simply 'by hand' comment-out the first part in the config file RcppArmadilloConfigGenerated.h.in (ie this file) and/or of course the created file RcppArmadilloConfigGenerated.h) the warnings should go away.

In other words I just want you to check whether on your normal, current, working system the warnings go away. I am not asking you to change your configuration, rather I am looking for active confirmation that libRlapack.* is now good enough. Makes sense?

[barracuda156]

I will try and let you know.

[eddelbuettel]

Sounds good. Forgot to add of course that both the warnings should go away yet all your functionality should remain as is. The warning really is just noise as best as I can tell.

[barracuda156]

@eddelbuettel I think build from 7124af9 works fine. I do not get an error about missing armadillo header and no more warnings about “crippled LAPACK” when building mlpack.

[eddelbuettel]

Thank you for testing and confirming. Those changes should make it to CRAN 'due course', likely early next week.