On Thu, Feb 27, 2003 at 03:55:13PM +1100, Stas Bekman wrote:
Greg Stein wrote: ...
You have to use a runtime check. It is too easy to slide in a library that is different from what you compiled against. Our compatibility guidelines are designed specifically to enable that kind of forward/backward change.
Compile-time checks are only useful to look for API changes as a way to decide how to call into APR. If the API is the same, and you're trying to test for an underlying bug, then you'll need to use a runtime check.
And all of this remains a bit fuzzier during pre-1.0 days. It might be possible in certain cases to look for bug fixes, and rely on incompatible APIs between patch levels to prevent the erroneous usage of an older library. But that's your call, and to be made on a case-by-case basis.
Greg, I'm not following you 100%.
If the app was compiled against specific apr_version.h, why not have a check at the boot time whether the binary library matches? That's what httpd does for modules it tries to load. Can't we do the same for apr?
Yes, you could do that, but I'd say that it is circumventing the desired usage policy of the library.
To be concrete:
* the APR versioning policy implies that we number releases as MAJOR.MINOR.PATCH
oops, I've completely forgotten about the MAJOR :)
* further, it states that versions differing only in the PATCH number should be completely interchangeable -- only bug fixes. no application should see any behavior change, other than to see a reduction in bugs
Thus, if you write the application to require a specific PATCH level, then you're defeating the intended policy. Doable, of course, but not nice :-)
Nope, I should have said MAJOR.MINOR. And no, not requiring a specific a minimum MAJOR.MINOR but only checking that the library in use is the same as the one the app that was compiled against.
[...]
I would normally advocate trying to run against as many versions as possible, and using runtime checks to arbitrate your usage of the library. If you ever code up a compile time check, and you compile against rev X.Y, then your installer should require that (at least) X.Y has been installed. [ cuz you might not even be able to load/link against X.(Y-1) ]
That's clear.
Finally the run-time check that you are talking about is the following? APR_DECLARE(void) apr_version(apr_version_t *pvsn);
Yup.
Fetch the structure and look at its values. It has everything you'd need.
but this incurs run-time overhead. So if I could avoid it, it's a goodness.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
