In the current development version of later, we introduced a new CCallable, execLaterNative2, which is called from inst/include/later.h. This header is compiled into other packages, like promises and httpuv. Here's the potential problem: if httpuv is compiled with the new version of this header (with execLaterNative2), and then run with the old version of later (with a DLL that does not have execLaterNative2), then it will throw this error when httpuv is loaded:
> loadNamespace('httpuv')
Error in dyn.load(file, DLLpath = DLLpath, ...) :
function 'execLaterNative2' not provided by package 'later'
This scenario could happen if:
We release the new version of later to CRAN, which triggers a rebuild of downstream dependencies (like httpuv).
A user installs a binary build of httpuv from CRAN which is compiled against the new version of later.
They do not upgrade later itself.
This PR so far illustrates how we could check if the later DLL has the old API (without execLaterNative2), which we'll call the V1 API. The API provided by this version of later is V2.
Checking for the old API version is somewhat awkward, but going forward, we have two simpler options for retrieving the API version that the package was built with:
Add a C++ function later::apiVersion() which returns the API version that the DLL was built with.
Add an R variable later:::api_version which returns the API version that the package was built with.
Then when later.h does its initialization stuff, we could check those values against the API version specified in the header.
wch
commented
5 years ago
In the current development version of later, we introduced a new CCallable,
execLaterNative2, which is called from inst/include/later.h. This header is compiled into other packages, like promises and httpuv. Here's the potential problem: if httpuv is compiled with the new version of this header (withexecLaterNative2), and then run with the old version of later (with a DLL that does not haveexecLaterNative2), then it will throw this error when httpuv is loaded:This scenario could happen if:
This PR so far illustrates how we could check if the later DLL has the old API (without
execLaterNative2), which we'll call the V1 API. The API provided by this version of later is V2.Checking for the old API version is somewhat awkward, but going forward, we have two simpler options for retrieving the API version that the package was built with:
later::apiVersion()which returns the API version that the DLL was built with.later:::api_versionwhich returns the API version that the package was built with.Then when later.h does its initialization stuff, we could check those values against the API version specified in the header.