[R] Issues with configure script

[Enchufa2]

Describe the bug, including details regarding any error messages, version, and platform.

I found two issues with the latest rewrite of the configure script for the R package:

1. There's a new script to check whether the library version and the R package version are compatible. This is fine, but for arrow 11, there are versions 11.0.0.2 and 11.0.0.3 on CRAN. The script does not remove the fourth component, and thus it stops when it finds that 11.0.0 != 11.0.0.3. My understanding is that versions a.b.c.d of the R package should be considered compatible to a.b.c of the library.
2. LIB_DIR is hardcoded here to something/lib. In many systems, this is lib64, not lib, and pkgconfig provides this info.

Component(s)

R

[thisisnic]

@nealrichardson Would you mind taking a look at this one?

[nealrichardson]

Thanks for the report!

1. There's a new script to check whether the library version and the R package version are compatible. This is fine, but for arrow 11, there are versions 11.0.0.2 and 11.0.0.3 on CRAN. The script does not remove the fourth component, and thus it stops when it finds that 11.0.0 != 11.0.0.3. My understanding is that versions a.b.c.d of the R package should be considered compatible to a.b.c of the library.

Have you encountered a scenario where you have a C++ library with version x.0.0.2 and R package with x.0.0.3? The .d releases are typically things we have to do to patch the R package for CRAN, so there is no corresponding C++ release with .d.

2. LIB_DIR is hardcoded here to something/lib. In many systems, this is lib64, not lib, and pkgconfig provides this info.

Good catch. It was always hard-coded for the non-pkg-config path, and I found that the previous way we were doing it with pkg-config, of using sed to get it from --libs-only-L, didn't behave well if there were other dirs in the search path, so I just dropped back to the hard-coded for all. But it looks like arrow.pc does include it as libdir, so we can get it as --variable=libdir for that case.

[Enchufa2]

Have you encountered a scenario where you have a C++ library with version x.0.0.2 and R package with x.0.0.3?

No, I've encountered a scenario where I have a C++ library with version x.0.0 and R package with x.0.0.3. That happened with x=11.

The .d releases are typically things we have to do to patch the R package for CRAN, so there is no corresponding C++ release with .d.

Exactly, so my expectation is that R package x.0.0.3 should find C++ library version x.0.0 as compatible. And it does not currently.

[nealrichardson]

Ah, got it, thanks