Accommodating breaking upstream changes

[eddelbuettel]

Upstream has commenced work on a new Armadillo 15.0 branch. It brings fp16 (for the currently still few, mostly arm64-based systems as well as some very high-end server cpus with AVX512-FP16 support) and turns off C++11 support (!!).

That second change, unsurprisingly, would lead to a ton of undesirable breakage at CRAN (short log), if released there. One possible remedy is to offer 14.6.2 as a drop-in fallback given that we can control Armadillo access via a single (!!) #include. The code is in branch armadillo/arma_15.0 and accomplishes this via simple if statement:

RcppArmadillo/inst/include/RcppArmadillo/interface/RcppArmadilloForward.h

Lines 49 to 66 in 04afddb

	#if __cplusplus >= 201402L
	// Armadillo 15.0 (rc)
	#include "current/armadillo"
	#else
	// we include Armadillo 14.6.2 here -- the last version to not require C++14
	#pragma message("Using fallback compilation with Armadillo 14.6.2 under C++11. Please consider removing the C++11 compilation standard directive.")
	// Armadillo has deprecation warnings (which RcppArmadillo suppressed at time to
	// minimise issies at CRAN). Should your package display any, and you decide
	// _not_ to fix the root causes (see RcppArmadillo GitHub Issues #391 and #402
	// for details) then defining the following macro will help. You can add a
	// #define in your source code before including the RcppArmadillo header, or add
	// a -DARMA_IGNORE_DEPRECATED_MARKER to the PKG_CPPFLAGS in src/Makevars.
	// Renabling globally for Armadillo 14.6.2 release
	#define ARMA_IGNORE_DEPRECATED_MARKER
	#include "legacy/armadillo"
	#endif

This is currently being reverse-dependency tested and looks good so far.

[eddelbuettel]

In an initial reverse-dependency check the new 'rc' code showed a regression in two packages which was communicated upstream. However, one of these is also a known issue at CRAN. The other appears to not fully reproducible.

Follow-up 2025-08-14: Contacted upstream by email.
Follow-up 2025-08-19: One of the two breaking packages has been updated at CRAN and no longer exhibits the issue.
Follow-up 2025-08-19: The other still breaks under the current rc (ie '14.90.10-5') and constitutes a regression