I'm not talking about the version_code argument, but checking
SANE_CURRENT_MAJOR in the backend. Let me quote from the docs:
# SANE_CURRENT_MAJOR:
# The value of this macro is the number of the SANE standard that
# the interface implements.
# ..., a backend always provides support for one and only one version of the
# standard.
This seems to imply that any backend has to look at SANE_CURRENT_MAJOR
to check if it's compatible with the interface (i.e., the library).
# SANE version control also includes a minor version number and a build
# revision. While control of these numbers remains with the implementor
# of a backend, the recommended use is as follows. The minor version is
# incremented with each official release of a backend. The build
# revision is increased with each build of a backend.
English is not my first language, but "these numbers" obviously refers to
"a minor version number and a build revision". This whole paragraph clearly
says that a backend has no control over it's own major version number - only
the minor number and build revision. Conclusion: The backend's major number
has to match the SANE major number.
If my interpretation is wrong, the paragraph should be rewritten to avoid
further mistakes - and this check removed from snapscan.c:
/* version check */
if (V_MAJOR != EXPECTED_MAJOR)
{
DBG (DL_MAJOR_ERROR,
"%s: this version of the SnapScan backend is intended for use\n"
"with SANE major version %ld, but the major version of this SANE\n"
"release is %ld. Sorry, but you need a different version of\n"
"this backend.\n\n",
me, (long) /*SANE_CURRENT_MAJOR*/V_MAJOR, (long) EXPECTED_MAJOR);
return SANE_STATUS_INVAL;
}
Regards,
Ingo
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com