From 4f986ec6431b6f3f8c951c70a02300d552cd8e02 Mon Sep 17 00:00:00 2001 From: Karen Arutyunov Date: Tue, 7 Jan 2020 22:10:14 +0300 Subject: Add implementation --- libz/build/bootstrap.build | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 libz/build/bootstrap.build (limited to 'libz/build/bootstrap.build') diff --git a/libz/build/bootstrap.build b/libz/build/bootstrap.build new file mode 100644 index 0000000..4bd5a50 --- /dev/null +++ b/libz/build/bootstrap.build @@ -0,0 +1,40 @@ +# file : build/bootstrap.build +# copyright : Copyright (c) 2016-2019 Code Synthesis Ltd +# license : zlib License; see accompanying LICENSE file + +project = libz + +using version +using config +using dist +using test +using install + +# zlib version has the ..[.] 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 ... 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...[.] (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?" -- cgit v1.1