I have memories of having fought this before, making me unlikely to wanting to return to this.bash it is. I generally change these things only when CRAN asks me too, and as it works even on their Solaris machine the status quo may not change easily.

We also recommend filing an issue ticket prior to making PRs to not waste effort.

So let's turn this then into the issue you never filed: What type of platform would require this?

Thank you for quick feedback.

NetBSD is one of the platforms requiring this change. I am a developer ofpkgsrc, the package management system for NetBSD and many other OS's, and had to add this change as a local patch when I packaged RcppArmadillo for pkgsrc.

I understand your concern about potential problems a build script change like this may cause. However, this PR is not adding anything that RcppArmadillo is not already using. RcppArmadillo'sconfigure uses= (mostly autoconf-generated) more often then==.

❯ grep "if test " configure | grep " = " | wc -l      33❯ grep "if test " configure | grep " == " | wc -l       6

and evenconfigure.ac has one:

❯ grep "if test " configure.ac | grep " = "if test "${GXX}" = yes; then

So, changing== to= is not only for portability but also for consistency.

FWIWs1 = s2 is mandated by POSIX (https://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html), whiles1 == s2 is not. So I would agree that using= rather than== is warranted for portability (even ifbash remains the default shell as appropriate).

As far as I know,== is abash-ism that does exactly the same thing as=, so there shouldn't be any risk.

I looked more closely (now that I am back from traveling) and the changes toconfigure.ac are pretty short and sweet and straight (and affect mostly contributed code, hi@kthohr ;-) ) so I think I'll just merge this. (And we didn't really need a change toconfigure as it gets generated anyway but doesn't hurt...)

#170

Some of those pre-dated my PR ;-)

;-) No worries.