On Tue, Nov 12, 2019 at 11:37:29PM +0100, Thomas Schmitt wrote:
>Hi,
>
>while exploring the need for adaptions in the build system of libsofs,
>i wonder whether it is really necessary to create LIBJTE2 in libjte.ver.
>Adding new functions is upward compatible.
>In my libraries i add them to the current (and only) SONAME version.
>
>Fine check for compatibility happens at compile time by the required
>minimum version (e.g. iso_libjte_req_* versus LIBJTE_VERSION_*) and
>at run time by calling libjte__is_compatible().
>
>If libisoburn gets a configure.ac test for existence of
>libjte_set_checksum_algorithm(), a compiler macro to enable its use,
>and a configure option to disable it despite being available,
>then it can even be built with the older libjte.
>(Fully autostylish.)
>
>So how about this in libjte/libjte.ver ?
>
> LIBJTE1 {
> global
> ...
> libjte_get_next_message;
> libjte_clear_msg_list;
>+ libjte_set_checksum_algorithm;
>+ libjte_set_checksum_path;
>+ libjte_add_checksum_demand;
>+ libjte_decide_file_jigdo2;
>+ libjte_write_match_record2;
> local:
> *;
> };
Surely that works for upwards compatibility, but won't stop somebody
from building and depending on the newer libjte2 then trying to run a
binary with libjte1?
>(Good news is that even libjte2 would probably not cause changes in the
> build system of libisofs. Currently it depends only on <libjte/libjte.h>
> and on libjte.so. I hope that both can keep their names.
> debian/control depends on libjte1 indirectly via libjte-dev.
> Adding "(>= 2.0.0)" would not really be necessary.)
Yeah, that side's easy.
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
