blob: 10e9b8a20d561afaf24520f1ba596842d29e7bb7 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
# file : build/bootstrap.build
# license : zlib License; see accompanying LICENSE file
project = libz
using version
using config
using dist
using test
using install
# zlib version has the <major>.<minor>.<revision>[.<subrevision>] form
# (ZLIB_VER* macros in zlib.h). The version increment rules are not documented
# and are hard to deduce. A subrevision release may contain a lot of changes
# (see 1.2.7.1) and a revision release may contain very few of them (see
# 1.2.8).
#
# Instead of dragging the fourth component around (and not being able to use a
# lot of tooling support) we are going to map the upstream version to the
# standard version as <major>.<minor>.<revision * 100 + subrevision>. Note
# that subrevision does not exceed 0xF (see ZLIB_VERNUM macro in zlib.h). Note
# that while there are no guarantees that this version follows the semver
# semantics, it's probably reasonable to assume this is the case.
#
# There is no documentation that describes libz ABI versioning and
# compatibility rules, so everything that follows is deduced from Makefile.in.
#
# The library naming scheme on Linux is
# libz.so.<major>.<minor>.<revision>[.<subrevision>] (SHAREDLIBV in
# Makefile.in). So presumably major is incremented on backwards-incompatible
# ABI changes.
#
if ($version.major == 1 && $version.minor == 2 && $version.patch == 1100)
{
abi_version_major = 1
abi_version = "$abi_version_major.2.11" # ...11.1 for subrevision 1, etc.
}
else
fail "increment the ABI version?"
|
