Closed eddelbuettel closed 2 years ago
Some follow-up:
so this looks to pretty close. I apparently just need one uname
call to R_ARCH
to arm64.
Looks like I was wrong -- this is actually an error in your scripts which does not seem to propage ARCH
as third argument but rather sets ""
consistently. I guess that needs a fix in cmake_call.sh
.
Also, nlopt_cleanup.sh
uses R_ARCH
, others use ARCH
. Hm.
Looks like I was wrong -- this is actually an error in your scripts which does not seem to propage ARCH as third argument but rather sets "" consistently. I guess that needs a fix in cmake_call.sh. Also, nlopt_cleanup.sh uses R_ARCH, others use ARCH. Hm.
I use the $ARCH
variable (which I create myself) only in configure.win
because I need to loop over the two architectures on Windows until next R release.
This is why in the configure
file which is used on Linux and macOS, I call the script with ARCH=""
, because there is no bi-architecture there.
This is a different environment variable w.r.t. $R_ARCH
which is defined in the config.site
of R itself.
But maybe I had it wrong in some places, causing install to fail on some platforms.
Following up on the use of GH actions, I like to setup continuous integration this way but I agree that it should not spam others' forks. This is annoying. I will look into it.
As for the automatic R CMD check
, it is triggered by the PR. But it should not have failed.
Looking at the details it seems the set up phase of downloading some other GH action script failed.
I will look at that later once the PR is merged.
Thanks for pointing that out too.
That makes sense as Windows (for a few more months til R 4.2.0 which will drop i386 at long last) is the only bi-arch platform.
It may have gotten side-tracked by the arm fail.
Good. It will indeed be easier when next R release will be out. Do you still intend to push some more commits or should I merge ?
If you have a moment, please review this PR as it stands. I have not checked if it bites Windows (should not, has its own file), and I was taken aback when the CI checks failed. If you find it suitable, merge ahead.
For completeness, my tarball that failed at RHub's M1 machine also passes in NZ on the mac-builder: https://mac.r-project.org/macbuilder/results/1642018536-d00f808ac7702ef6/
It passes. The supposed Windows failure is an 'WARNING as ERRORS' setting I would never turn on.
But I added src/nlopt/
to .Rbuildignore
which I should have caught earlier.
Hah -- misses the final comment :) as "resolved" hides the conversation. Coming right up, and indeed easiest in an added YAML. I will permit myself to use my form there.
I rushed this -- it runs Ubuntu 20.04 where we do not yet have NLopt 2.7, and for symmetry with your approach I made that a minimum requirement. 2.6 is likely good enough, but I will ~pivot the yaml to Debian testing instead. One sec and now I can dry-running in Docker here before committing.~ make sure I have NLopt 2.7 available for ubuntu-20.04. It'll take a moment.
Weeee -- that turned into a comedy of errors but here we are now. "Proof" of it working on all platforms we care about in all deployment forms.
That seems quite neat, thank you. I will merge this.
Thanks for bearing with me and working through the changes. We are in a good spot now.
Thanks to you. Since CRAN seems not to answer me about my previous submission, I'll just resubmit this one and see if it can unlock the situation.
Communicating with them is "challenging" -- but then again there are only a handful or so of them, and literally over a thousand of us bugging the,. Patience is good but we may now be getting there.
I ran further checks on win-builder release and devel. It succeeds on the release version but cannot find cmake
on the win-builder devel.
I also ran checks on some r-hub platforms again and all is good except Windows that came back with the following warning that was already reported in #85.
I might have to go there and tweak the source file. Or file an issue in the nlopt
repo but we need a reply soon.
I will make another submission maybe as it is now in the meantime because windows checks by CRAN are made on win-builder which goes well except on the devel version but it's out of my hands that cmake cannot be found there. I do not know who to ask to install cmake
on the win-builder devel machine. It seems quite strange that it is found on the release machine and not the devel one.
but cannot find
cmake
Well I tried to explain at the very beginning. Few CRAN packages do what you do. CRAN may not be ready, but if you ask nicely they may move along and install it. Re-read Writing R Extentions. Just because you declare something a system dependency does not mean it will be provided.
I do not know who to ask to install cmake on the win-builder devel machine
Email cran@r-project.org and/or for Windows issues Dr Uwe Ligges at U Dortmund.
It seems quite strange that it is found on the release machine and not the devel one.
See above. You may live in a cmake
world, but CRAN and most of the R ecosystem do not. It's a risk you took, knowingly or not.
FWIW, Dirk, in 2017 you commented that you could find 47 packages that were on CRAN and used cmake
by searching for CMakelists.txt
. Now there seems to be only one, https://github.com/davidcsterratt/geometry/tree/5e6fa7e88f9b93a9841c6da2b180442b43afb8ef ... ?
Definitely more. From the top of my head Joe's httpuv
does the same (of launching into a cmake build of a library). Back then when I had shell access to a directory of unpackaged CRAN packages for grepping, I no longer do,
Expanding the search to cmake
gets 943 hits, number of repos surely a subset.
Per the earlier discussion here is (minimal) layer reusing an existing
nlopt
installation (and not requiring) cmake.On Linux (Ubuntu 21.04) with nlopt present (and sufficiently recent)
On Linux (Docker container with Debian testing,
cmake
andtestthat
added, no nlopt presentI can probably try a RHub test build on a few Linux or macOS variants there. They should all reliably call
cmake
.