libburnia/libisoburn
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Version leap to 0.1.1

Browse Source
This commit is contained in:
Thomas Schmitt
2008-02-15 21:19:24 +00:00
parent 33e666da11
commit 5163a66a02
11 changed files with 116 additions and 92 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
libisoburn/libisoburn.h
View File

@ -62,12 +62,12 @@ libburn demands rw-permissions to drive device file resp. file object.
If the input drive provides a suitable ISO RockRidge image, then its tree
may be loaded into memory and can then be manipulated by libisofs API calls.
The loading is done by isoburn_read_image() under control of
struct isoburn_read_opts which the application obtains from libisoburn.
It may be manipulated by the family of isoburn_ropt_set_*() functions.
struct isoburn_read_opts which the application obtains from libisoburn
and manipulates by the family of isoburn_ropt_set_*() functions.
Writing of result images is controlled by libisofs related parameters
in a struct isoburn_imgen_opts which the application obtains from libisoburn.
It may be manipulated by the family of isoburn_igopt_set_*() functions.
in a struct isoburn_imgen_opts which the application obtains from libisoburn
and manipulates by the family of isoburn_igopt_set_*() functions.
All multi-session aspects are handled by libisoburn according to these
settings. The application does not have to analyze media state and write
@ -164,12 +164,19 @@ int isoburn_is_compatible(int major, int minor, int micro, int flag);
Pare numbers indicate a version with frozen API. I.e. you can
rely on the same set of features to be present in all
published releases with that major.minor.micro combination.
Features of a pare release will stay available and ABI
compatible as long as the SONAME of libisoburn stays "1".
Currently there are no plans to ever change the SONAME.
Odd numbers indicate that API upgrades are in progress.
I.e. new features might be already present or they might
be still missing.
be still missing. Newly introduced features may be changed
incompatibly or even be revoked before release of a pare
version.
So micro revisions {1,3,5,7,9} should never be used for
dynamic linking unless the proper library match can be
guaranteed by external circumstances.
@return 1 success, <=0 might in future become an error indication
*/
void isoburn_version(int *major, int *minor, int *micro);
@ -224,13 +231,13 @@ int isoburn_libburn_req(int *major, int *minor, int *micro);
@since 0.1.0
*/
#define isoburn_header_version_major 0
#define isoburn_header_version_minor 0
#define isoburn_header_version_minor 1
#define isoburn_header_version_micro 1
/** Note:
Above version numbers are also recorded in configure.ac because libtool
wants them as parameters at build time.
For the library compatibility check ISOBURN_*_VERSION in configure.ac
are not decisive. Only the three numbers above do matter.
For the library compatibility check, ISOBURN_*_VERSION in configure.ac
are not decisive. Only the three numbers here do matter.
*/
/** Usage discussion:
@ -273,8 +280,20 @@ at the cost of excluding some older libraries.
These two advises are mutually exclusive.
-----------------------------------------------------
For an implementation of the Thomas Schmitt approach,
see libisoburn/burn_wrap.c : isoburn_initialize()
This connects libisoburn as "application" with libisofs
as "library".
The compatible part of Vreixo Formoso's approach is implemented
in configure.ac LIBBURN_REQUIRED, LIBISOFS_REQUIRED.
In isoburn_initialize() it would rather test by
iso_lib_is_compatible(isoburn_libisofs_req_major,...
than by
iso_lib_is_compatible(iso_lib_header_version_major,...
and would leave out the ugly compile time traps.
*/