Closed jeroen closed 1 year ago
The build works, but one of your tests has a weird error: Cannot supply LdFlags as none
. I think your tests are assuming that quantlib-config
is always available? (which is not the case for static lib or prebuilt binaries).
I think your tests are assuming that quantlib-config is always available?
Is it my tests, or my 'ad-hoc' build script used by the test? It could just be the latter.
Feel free for brute force testing to comment out the overtall hook into tinytest
from tests/tinytest.R
. If we have a build working (and I really appreciate the helping hand!) we can possibly tweak the rest in step two.
OK I disabled that test on mac (that was already disabled on windows) so the build passes now.
Nice.
In the flurry you may have missed what I asked earlier
Is that 'mac' directory at CRAN browseable?
I.e. can I know how old his packages are? But I answered that by pointing a browser at https://mac.r-project.org/bin/darwin20/arm64/. Looks like Simon updates once a year or more often if he musts.
They updated the libs last month for the R 4.3 release, but I suspect not much updates for another 2 years after this until they bump to a new macos version.
Of course now I have to figure out how to only trigger macOS when I have the patience for it :)
The build will be a bit faster if you mirror those 4 files to some of faster server (or just anywhere on github): https://github.com/eddelbuettel/rquantlib/blob/af4e4c681207b5216e65712046e2976b52512e4b/configure.ac#L93-L99
Either way good luck, I'm done for the day.
This will allow the package to be built in CI or r-universe or by mac users locally, with the same quantlib as CRAN.
On systems where
quantlib-config
is found (such as cran itself), that configuration is used, and nothing is downloaded. So it functions as a fallback method for mac systems where quantlib is not available.PS: if you use this, I recommend mirroring the downloaded files from cran somewhere (e.g. github release assets) because
mac.r-project.org
is pretty slow and flaky.