search

eddelbuettel / rquantlib

R interface to the QuantLib library
117 stars 50 forks source link

Feature Request for CRAN macOS Systems: Upgrade QuantLib and Boost? #191

Open eddelbuettel opened 3 weeks ago

eddelbuettel commented 3 weeks ago

This is not a bug report for RQuantLib but more of a (very, very gentle) nudge for @s-u who looks after the macOS machines for CRAN. "Currently", and for some time now, these system nag about 'upcoming Boost changes in April 2023' which have of course long passed. Similarly, C++14 is no longer all that novel given that the last two R releases set C++17 as a common base level (where supported by compilers).

So with that, if you could find a moment to update QuantLib and Boost I would greatly appreciate it.

image

eddelbuettel commented 2 weeks ago

@s-u : Gentle nudge in case you had not seen this issue as it is understood that we are all busy...

s-u commented 2 weeks ago

@eddelbuettel Please add a PR or issue to https://github.com/R-macos/recipes/issues with exact details (including requested version for each library).

eddelbuettel commented 2 weeks ago

Done in https://github.com/R-macos/recipes/issues/55 -- the guilty party really was the older QuantLib, Boost was already pretty current. Hopefully this should carry us for a year or two.

eddelbuettel commented 1 week ago

@s-u Despite https://github.com/R-macos/recipes/issues/55 being filed and merged this still fails here as shown below. Could I ask you to check if the updated recipes have actually been deployed in the tests, and if not, if there is something I can to help?

image

s-u commented 1 week ago

@eddelbuettel I don't see any RQuantLib updates (last submission + build was Aug 1). Since this is no ERROR, it won't be re-built automatically against the new libraries until the next submission, so if you really want a manual re-build of the same package version, you'd have to let me know.

eddelbuettel commented 1 week ago

@s-u The CRAN page is then hard to read / misread by me. It gives current dates:

image

The logs for a particular run do not show if they are current or stale. I take your word that they are stale; if I had updated my infra (as you apprently so kindly did per my request_ I would have thought to also re-run with the now-updated infra. You may be aware that there is friction and 'cost' to new CRAN uploads so us paesants tend to minimize the frequency of such uploads.

Looking at a particular log (https://www.r-project.org/nosvn/R.check/r-oldrel-macos-arm64/RQuantLib-00check.html) it is true that it doesn't even show a date. IIRC the one from Oxford and Vienna tend to do that.

Anyway, point taken. I'll have to live with the :x: til the next upload.

s-u commented 1 week ago

@eddelbuettel I don't see dates on any of them - that would be a feature request for R CMD check. The webpages are generated from the logs, but apparently they only show the date of the html generation, not the date of the log - it sounds like something that could be useful.

As for re-builds, it is really a question of urgency: unfortunately, we don't have a way to distinguish binary versions in R, so there is no way to "update" a binary version. If you are just worried about the checks, then it's quite simple to re-run those, but whether it is worth it is your call - as noted the system itself doesn't care about anything less than an ERROR.

eddelbuettel commented 1 week ago

@s-u :

1) Yes a quick date call would be nice. I seem to recall some logs on some platforms have that. I could be wrong.

2) Yes an ability to 'poke' a rebuild would be nice too. Jeroen gives us that at r-universe (in case of a fail in prior run).

I am sure you are aware we as developers get nagged on NOTE and WARNING and the whole point of updating libquantlib (and boost) was to avoid one on your systems. So now my hands are tied but that is the hand we're dealt here so we play it.