>[EMAIL PROTECTED] wrote: >... >I'd enthusiastically support a richer macro to express a >data-by-call dereference, but that's not possible until APR >1.3 at earliest due to the versioning rules. Since 1.3 is in >development, that's the best version to target for such a change.
Ah, but this change would not need to cause binary or even source incomptibilities for other OS versions. This example is now from APU, to be a little less convoluted since here data and not data arrays are exported. In apr_hooks.h there is the line APU_DECLARE_DATA extern apr_pool_t *apr_hook_global_pool; which in the Symbian version now looks like APU_DECLARE_EXPORTED_DATA(apr_pool_t *, apr_hook_global_pool); When APU_DECLARE_EXPORT is defined, that is, when the apu library is being built, it expands into APU_DECLARE_DATA extern apr_pool_t *apr_hook_global_pool; In other words, components built into the apu library sees that variable directly. When APU_DECLARE_EXPORT is not defined, it expands into APU_DECLARE(apr_pool_t*) _apr_hook_global_pool(void); in which case the define #define apr_hook_global_pool (*_apr_hook_global_pool()) also becomes visible. That is, components not built into apu uses that variable indirectly via a function call. But on the source code level there is no difference. Now, in the case of all other operating systems, we could simply have #define APU_DECLARE_EXPORTED_DATA(type, name)\ APU_DECLARE_DATA extern type name If that also would cause a change in the minor number, then I would be perfectly happy with #if defined(__SYMBIAN32__) APU_DECLARE_EXPORTED_DATA(apr_pool_t *, apr_hook_global_pool); #else APU_DECLARE_DATA extern apr_pool_t *apr_hook_global_pool; #endif which would cause no changes for other Oss and thus could be introduced as a patch? My assumption is that there is less overhead for httpd to take an APR version into use where only the patch number and not the minor number has changed. And I'd really like to be able to start working for the Symbian httpd modifications to be accepted. Br, Johan
