R package build from source failing on Conda Forge

[mfansler]

We're seeing an error on the Conda Forge builds for this package. Essentially, we download and unpack the tarball from CRAN, then run

R CMD INSTALL --build .

However, this has been resulting in a configure error since v0.5.22:

* installing to library ‘/home/conda/feedstock_root/build_artifacts/r-isotree_1701323302199/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/lib/R/library’
* installing *source* package ‘isotree’ ...
** package ‘isotree’ successfully unpacked and MD5 sums checked
** using staged installation
configure: error: cannot find sources (isotree) in . or ..
ERROR: configuration failed for package ‘isotree’

Any idea why this would be happening? Are changes in the configure script incompatible with installing from unpacked source?

Thanks in advance for any insight!

[david-cortes]

Thanks for the bug report and sorry about these problems. The latest version of this package requires R >= 4.3.

While that requirement is currently (0.5.24-1) added to DESCRIPTION, I unfortunately forgot to add that requirement to one of the last CRAN uploads (0.5.24), so it's currently failing in some CRAN checks which aren't pulling the latest version of this package.

I was informed by CRAN that I need to solve this issue, so I'm thinking of the following workaround:

• Upload last version that worked with older R (0.5.22) to CRAN with a newer version string than the current one (so that it would now have version number 0.5.24-2).
• Wait until all tests for it pass, particularly on oldrel checks.
• Re-upload the current version (0.5.24-1) as yet another newer version string 0.5.24-3.

First step should be completed very soon.

[mfansler]

Thanks for the heads up. Just FYI, that we still see the same issue in 0.5.24-2 (Conda Forge PR). I think unlike CRAN, we unpack the tarball before building from source and the configure file seems somehow to be incompatible with this.

[david-cortes]

Thanks for the information. I am unfortunately not familiar with conda packaging so I'm afraid I cannot offer much help.

A couple thoughts:

• I see the PR you linked changes a parameter in recipe/meta.yaml from build.number = 1 to build.number = 0. Could that be causing an issue?
• The only changes in the configure script have been in removing the package version from the script. Would it make a difference if you add them back by copying the configure that was working from an older version?
• Is it possible to modify package files for the conda build? If so, since you are already defining the environment with which to build, maybe you could do away with the configure and Makevars.in by simply adding a Makevars file like this:

  PKG_CPPFLAGS  =  -DRCPP_USE_UNWIND_PROTECT -D_FOR_R -D_USE_XOSHIRO -D_USE_ROBIN_MAP -DSUPPORTS_RESTRICT=1 
  PKG_CXXFLAGS  =  $(SHLIB_OPENMP_CXXFLAGS) -fno-math-errno -fno-trapping-math $(CXX_VISIBILITY)
  PKG_LIBS      =  $(SHLIB_OPENMP_CXXFLAGS)
  CXX_STD       =  CXX17

Are you able to provide a Dockerfile here that would reproduce the error that you are seeing?

[david-cortes]

Also, I'm not sure if I got this right, but from some quick look at the logs there, it looks like you are extracting the package's contents to this folder:

/home/conda/feedstock_root/build_artifacts/r-isotree_1701432284233/work

Which is saved in env. var SRC_DIR.

However, I don't see this SRC_DIR later on used to specify some R env. var or path, only cmake variables. Do those still work for autoconf?

[mfansler]

Thanks for the responses. Yes, we can easily swap in a fixed Makevars for the dynamic configure approach. I've done that and seems fine. 🚀

Some responses to your questions:

• build number: that is normal; we reset the build to zero whenever upstream changes version. Builds are for tracking a change in Conda recipe that still starts from the same source, for example, linking against a different version of a compiled library.
• SRC_DIR is the working directory when the R CMD INSTALL is called
• we could change the configure script (or rerun autoconf), but if we know exactly the configuration then that's a simpler alternative, IMO

For the configure script changes, I see you dropped the version in the configure.ac, but that actually removed a bit more info in the rendered configure file. Here's the relevant snippet of the diff at the bisection (0.5.20...0.5.22):

diff --git a/configure b/configure
index 7dbbffd..5512076 100755
--- a/configure
+++ b/configure
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.71 for isotree 0.5.18.
+# Generated by GNU Autoconf 2.71.
 #
 #
 # Copyright (C) 1992-1996, 1998-2017, 2020-2021 Free Software Foundation,
@@ -605,13 +605,14 @@ MFLAGS=
 MAKEFLAGS=

 # Identity of this package.
-PACKAGE_NAME='isotree'
-PACKAGE_TARNAME='isotree'
-PACKAGE_VERSION='0.5.18'
-PACKAGE_STRING='isotree 0.5.18'
+PACKAGE_NAME=''
+PACKAGE_TARNAME=''
+PACKAGE_VERSION=''
+PACKAGE_STRING=''
 PACKAGE_BUGREPORT=''
 PACKAGE_URL=''

+ac_unique_file="isotree"
 ac_subst_vars='LTLIBOBJS
 LIBOBJS
 LD_SUPPORT

[mfansler]

I'll leave this at your discretion to close or leave open. For practical purposes, I'm satisfied with the workaround. But it is an odd bug and first time I've seen it.

[david-cortes]

Thanks for the hint. I've added back the version number to the configure script in case it causes installation issues elsewhere.

Still odd that it fails like that, since running ./configure from the root folder of the de-compressed CRAN .tar.gz file works fine for me.

[mfansler]

Still odd that it fails like that, since running ./configure from the root folder of the de-compressed CRAN .tar.gz file works fine for me.

Yeah, I also did a local test on unpacked CRAN tarball and R CMD INSTALL --build . worked fine. 🤷

[david-cortes]

A wild idea: could it be that the environment you are using in the conda-forge build is using a shell with less features than mainstream ones like bash when executing the configure script, and the configure script somehow ended up including some non-posix code that's not supported there?